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Abstract of FR2794919 

The system includes addition of a third zone to 
the standard zones, to assist in routing over 
network bridge. The procedure provides a 
method of processing a data packet at the 
level of a bridge in a communication network. 
The data packet comprises a first reserved 
zone at least a part of which contains 
information identifying the route for the packet 
through the network. The packet also includes 
a second reserved zone containing the useful 
data. The procedure includes a stage of 
adding a third reserved zone providing 
additional information about the route for the 
packet through the network, completing the 
information held in the first reserved zone to 
indicate the route. The first reserved zone and 
the third reserved zone may have the same 
structure, but this can be different. Either or 
both these zones may be a header for the 
main useful data. 
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L'invention concerne un precede de traitement d'un 
paquet de donnees au niveau d'un pont d'un reseau de 
communication, ledit paquet de donnees comportant une 
premiere zone reservee au moins en partie a des informa- 
tions dites d'identification d'un chemin pour ledit paquet de 
donnees dans ledit reseau et une deuxieme zone compor- 
tant des donnees dites utiles, caracterise en ce que ledit 
procede comporte une etape d'ajout d'au moins une troisie- 
me zone reservee au moins en partie a d'autres informa- 
tions d'identification dudit chemin dans ledit reseau pour 
ledit paquet de donnees et qui completent lesdites informa- 
tions d'identification de ladite premiere zone pourconstituer 
ledit chemin. 
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La presente invention concerne un precede et un dispositif de 
10 traitement d'un paquet de donnees au niveau d'un pont d'un reseau de 

communication, ledit paquet de donnees comportant une premiere zone 

reservee au moins en partie a des informations dites d'identification d'un 

chemin pour ledit paquet de donnees dans ledit reseau et une deuxieme zone 

comportant des donnees dites utiles. 
15 On connaTt des reseaux de communication qui sont formes de 

plusieurs bus de communication serie conformes a la norme IEEE 1394. 

Ces bus sont organises en reseau, c'est-a-dire qu'ils sont relies 

entre eux par des equipements ou ensembles d'equipements que Ton nomme 

des "ponts" ("bridges" en terminologie anglo-saxonne). 
20 Un pont permet de transferer des paquets de donnees d'une 

premiere partie du reseau ou premier sous-reseau vers une deuxieme partie du 

reseau ou deuxieme sous-reseau par liaison filaire, optique, radio ou par tout 

autre type de liaison physique envisageable. 

Une partie d'un reseau est egalement appelee sous-reseau. 
25 Les ponts reliant entre eux des bus de communication serie font 

plus particulierement I'objet de la norme P1394.1 qui est en cours de 

discussion. 

Dans le cadre de cette norme, un pont comporte plus 
particulierement au moins deux equipements d'interconnexion appeles "portals" 
30 en terminologie anglo-saxonne et permettant de relier entre eux au moins deux 
bus de communication serie 1394. Un equipement d'interconnexion ou "portal" 
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est un ensemble de ports conformes a la norme 1394 et connectes a un bus de 
communication serie 1394. 

Chaque bus de communication serie d'un tel reseau relie 
differents equipements ou peripheriques entre eux tels que des imprimantes, 
ordinateurs, serveurs, scanners, magnetoscopes, decodeurs (connus en 
terminologie anglo-saxonne sous le terme de "set top box"), televiseurs, 
cameras numeriques, camescopes, appareils photographiques numeriques... 

Ces peripheriques sont egalement appeles noeuds. 

Chaque equipement ou peripherique situe sur un bus du reseau 
peur vouloir communiquer des informations a un autre equipement du reseau 
situe sur un autre bus du reseau, les deux bus sur lesquels ces equipements 
sont situes etant separes par un ou plusieurs ponts. 

Ainsi, chacun de ces ponts sera done amene a transferer de 
maniere selective ou non les informations echangees entre les deux 
peripheriques depuis I'un des bus connecte a I'un des equipements 
d'interconnexion ou "portals" dudit pont vers un autre bus dispose de I'autre 
cote dudit pont et connecte a un autre equipement d'interconnexion ou "portal" 
de ce meme pont. 

Chaque bus peut etre connecte a plusieurs autres bus par 
I'intermediaire de plusieurs ponts differents. 

Lorsqu'un equipement d'interconnexion ou "portal" recoit un 
paquet de donnees i! doit done pouvoir identifier si le paquet qu'il recoit est 
destine a un peripherique present sur son bus ou a un ou plusieurs des 
equipements d'interconnexion ou "portals" presents sur son bus. 

Pour ce faire, les informations vehiculees sur les differents bus du 
chemin que parcourt le paquet de donnees doivent indiquer la destination du 
paquet et chaque equipement d'interconnexion ou "portal" doit etre capable 
d'analyser cette destination pour transmettre les informations au peripherique 
destinataire. 

Dans les reseaux conformes a la norme IEEE-1394, I'adresse de 
la destination est codee dans un premier champ d'informations dit 
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(^identification de I'en-tete du paquet de donnees de longueur fixe, appele 
champ destination, et I'adresse de la source dudit paquet de donnees est 
codee dans un deuxieme champ d'informations dit d'identification de I'en-tete 
de longueur fixe, appele champ source. Ces deux champs sont distincts et leur 
5 longueur depend du protocole de communication. 

Dans les reseaux conformes a la norme IEEE-1394, le champ 
destination est par exemple code sur 16 bits et le champ source egalement. 
Ces 16 bits sont separes en 10 bits reserves au codage de I'identificateur du 
bus sur lequel se trouve le peripherique destinataire du paquet de donnees et 6 
10 bits reserves au codage de I'identificateur du peripherique destinataire sur ce 
bus. 

De tels reseaux de transfert de paquets de donnees necessitent 
un equipement centralise (connu sous le terme "prime portal" en terminologie 
anglo-saxonne) qui, lors de Initialisation du reseau, va attribuer un numero a 
15 chaque bus du reseau. Ensuite, apres cette etape de numerotation 
automatique, chaque equipement d'interconnexion ou "portal" de chaque pont 
va configurer une table de routage qui lui est propre en fonction des differents 
messages qu'il aura vu passer. 

Cette table de routage est par exemple representee par une 
20 succession de bits ou chaque bit correspond a un bus du reseau. 

Chaque bit sera positionne a la valeur binaire 0 ou 1, 0 si le pont 
ne doit pas transferer des donnees destinees a un peripherique present sur le 
bus correspondant a ce bit dans la table, et 1 si le pont doit transferer des 
donnees destinees a un peripherique present sur le bus correspondant a ce bit 
25 dans la table. 

Ces reseaux sont configures pour pouvoir interconnecter un 
nombre maximal de 1024 bus. Chaque table de routage doit done comporter 
1023 bits et chaque pont doit done comporter deux tables de routage de 1023 
bits puisque chaque portal est relie a des bus differents et doit done, de ce fait, 
30 posseder sa propre table. 
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Dans un tel reseau, lorsque le paquet de donnees arrive dans le 
pont, celui-ci lit le champ destination place dans I'en-tete de ce paquet de 
donnees et lit sa table de routage afin de determiner s'il peut transmettre le 
paquet au bus destinataire, c'est-a-dire si le bit correspondant a ce bus est 
positionne a "1" dans la table de routage. 

On connait des precedes de transfer! de paquets de donnees tels 
que celui decrit dans le brevet US 5 442 881, permettant de coder I'en-tete a la 
source. Le peripherique ou nceud source qui veut emettre un paquet de 
donnees connait le chemin qui le separe du peripherique destinataire auquel il 
veut transferer des donnees. Ce chemin est code dans un champ de l'en-t§te 
du paquet de donnees qui comporte toutes les adresses ou identifications des 
differents noeuds du reseau rencontres par ledit paquet de donnees sur son 
chemin. 

Lorsqu'un equipement de ce reseau, charge du transfert des 
paquets, recoit ie paquet de donnees, il decode cet en-tete et transmet le 
paquet au peripherique destinataire apres avoir modifie cet en-tete. 

On connait egalement le brevet US 5 613 069 qui decrit un 
precede de transfert de paquets dans un reseau a commutation de paquets, 
chaque paquet comprenant un champ d'en-tete de longueur variable pour 
decrire le chemin a parcourir ainsi qu'un champ de fin de paquet de longueur 
variable pour decrire le chemin parcouru. 

Toutefois, ce systeme s'applique a la commutation de paquets ou 
chaque port d'un commutateur est relie a un seul autre port d'un autre 
commutateur alors qu'un pont peut etre relie a plusieurs autres ponts via un 
meme bus. 

Ainsi, une telle solution n'est pas adaptee a etre mise en ceuvre 
dans un reseau du type de ceux presentes ci-dessus, conformes a la norme 
IEEE 1394. Dans ces reseaux, I'en-tete de chaque paquet de donnees 
comporte un champ destination et un champ source, dont 10 bits seulement 
sont reserves dans chacun d'eux au codage de Pidentificateur du bus sur lequel 
se trouve le peripherique destinataire ou source. 
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En effet, dans un n§seau du type conforme" a la norme IEEE 1394, 
dans le cas ou le nombre maximal autorise de chaque equipement 
d'interconnexion ou "portal" d'un pont sur un bus est de trois, il faut deux bits 
pour coder I'adresse ou I'identificateur de chaque equipement d'interconnexion 
ou "portal" de fagon unique. 

Le champ destination de I'en-tete des paquets de donnees peut 
done contenir quatre identificateurs d'equipements d'interconnexion ou "portals" 
differents. 

Le nombre maximal de ponts separant la source et la destination 
est done, dans cet exemple, de quatre. 

Ceci est restrictif et Ton constate que plus le nombre 
d'equipements d'interconnexion ou "portals" autorises sur un bus augmente, 
plus il est necessaire d'avoir un nombre eleve de bits pour coder I'identificateur 
de ces equipements d'interconnexion ou "portals" et done plus la distance 
maximale entre la source d'un paquet de donnees et sa destination est faible. 

D'une maniere gen6rale, il serait par consequent interessant de 
pouvoir augmenter la distance entre la source et la destination d'un paquet de 
donnees lorsque le champ dudit paquet qui est reserve a I'identification du 
chemin de ce paquet dans le reseau a une taille limitee. 

La presente invention vise ainsi a remedier a cet inconvenient en 
proposant un procede de traitement d'un paquet de donnees au niveau d'un 
pont d'un reseau de communication, ledit paquet de donnees comportant une 
premiere zone reservee au moins en partie a des informations dites 
d'identification d'un chemin pour ledit paquet de donnees dans ledit reseau et 
une deuxieme zone comportant des donnees dites utiles, caracterise en ce que 
ledit procede comporte une etape d'ajout d'au moins une troisieme zone 
reservee au moins en partie a d'autres informations d'identification dudit 
chemin dans ledit reseau pour ledit paquet de donnees et qui completent 
lesdites informations d'identification de ladite premiere zone pour constituer 
ledit chemin. 
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Correlativement, I'invention vise un dispositif de traitement d'un 
paquet de donnees au niveau d'un pont d'un reseau de communication, ledit 
paquet de donnees comportant une premiere zone reservee au moins en partie 
a des informations dites d'identification d'un chemin pour ledit paquet de 
donnees dans ledit reseau et une deuxieme zone comportant des donnees 
dites utiles, caracterise en ce que ledit dispositif comporte des moyens d'ajput 
d'au moins une troisieme zone reservee au moins en partie a d'autres 
informations d'identification dudit chemin dans ledit reseau pour ledit paquet de 
donnees et qui completent lesdites informations d'identification de ladite 
premiere zone pour constituer ledit chemin. 

Ainsi, I'invention permet, grSce a I'adjonction d'au moins une 
troisieme zone, d'etendre la zone du paquet de donnees qui est destinee a 
recevoir des informations d'identification dudit chemin dans ledit reseau pour 
ledit paquet de donnees. 

De ce fait, il sera possible de stacker dans le paquet de donnees 
ainsi "encapsule" davantage d'informations d'identifications de chemin que 
dans un paquet comportant seulement une premiere zone reservee a de telles 
informations. 

Selon une caracteristique, le precede comporte une 6tape 
d'ecriture des informations d'identification du chemin dudit paquet de donnees 
dans le reseau dans la premiere zone et ladite au moins une troisieme zone de 
ce paquet. 

On repartit ainsi les informations d'identification dans au moins 
deux zones et, si cela ne suffit pas, le paquet de donnees d'origine est 
"encapsule" autant de fois que cela est necessaire et les informations 
d'identification sont alors reparties dans plus de deux zones. 

Selon une caracteristique, la premiere zone et la au moins une 
troisieme zone du paquet de donnees ont une meme structure, ce qui facilite la 
mise en oeuvre de I'invention. 

Selon une caracteristique, la premiere zone et la au moins une 
troisieme zone du paquet de donnees ont chacune une structure differente. 
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Ceci permet d'optimiser le mecanisme d'ericapsulation. 

Cette caracteristique peut s'averer interessante dans certaines 

applications. 

Selon une caracteristique, la premiere zone du paquet de 
donnees constitue un en-tete qui est I'en-tete du paquet courant. 

Selon une caracteristique, ladite au moins une troisieme zone du 
paquet de donnees constitue un en-tete qui encapsule le paquet d'origine 
comportant les premiere et deuxieme zones. 

Selon une caracteristique, le paquet de donnees ayant une 
longueur donnee avant I'ajout de la au moins une troisieme zone et la premiere 
zone dudit paquet comportant des informations concernant la longueur de ce 
paquet , ladite au moins une troisieme zone comporte des informations 
concernant la longueur du nouveau paquet de donnees obtenu apres ajout de 
ladite au moins une troisieme zone qui different de celles de ladite premiere 
zone. 

Avantageusement, le fait de prendre la longueur du nouveau 
paquet apres encapsulation peut s'averer utile pour certains traitements. 

Selon une caracteristique, le paquet de donnees ayant un type 
donne avant ajout de la au moins une troisieme zone et la premiere zone dudit 
paquet comportant des informations concernant le type de ce paquet, ladite au 
moins une troisieme zone comporte des informations concernant le type du 
nouveau paquet de donnees obtenu apres ajout de ladite au moins une 
troisieme zone qui different de celles de ladite premiere zone. 

Cela s'avere necessaire lorsqu'on "encapsule" un paquet de type 
"quadlet data", c'est-a-dire, contenant quatre octets de donnees, le paquet 
obtenu apres "encapsulation" etant forcement d'un autre type ("block data") 
puisqu'il contient plus de donnees qu'avant. 

Selon une caracteristique, le type d'un paquet definit la fagon dont 
sont structures les donnees. 

Selon un deuxieme aspect, ('invention vise un precede de 
transfert d'un paquet de donnees au niveau d'un pont d'un reseau de 
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communication, ledit paquet de donnees comportaht une premiere zone 
reservee au moins en partie a des informations dites d'identification d'un 
chemin pour ledit paquet de donnees dans ledit reseau et une deuxieme zone 
comportant des donnees dites utiles, caracterise en ce que ledit procede 
comporte les stapes suivantes : 

- reception dudit paquet de donnees, 

-.detection d'au moins une troisieme zone ajoutee audit paquet, 
r6servee au moins en partie a d'autres informations d'identification dudit 
chemin dans ledit reseau pour ledit paquet de donnees et qui completent 
lesdites informations d'identification de ladite premiere zone pour constituer 
ledit chemin. 

Correlativement, I'invention vise un dispositif de transfert d'un 
paquet de donnees au niveau d'un pont d'un reseau de communication, ledit 
paquet de donnees comportant une premiere zone reservee au moins en partie 
a des informations dites d'identification d'un chemin pour ledit paquet de 
donnees dans ledit reseau et une deuxieme zone comportant des donnees 
dites utiles, caracterise en ce que ledit dispositif comporte : 

-.des moyens de reception dudit paquet de donnees, 
-.des moyens de detection d'au moins une troisieme zone ajoutee 
audit paquet, reservee au moins en partie a d'autres informations 
d'identification dudit chemin dans ledit reseau pour ledit paquet de donnees et 
qui completent lesdites informations d'identification de ladite premiere zone 
pour constituer ledit chemin. 

Lorsqu'une troisieme zone (en-tete) est detectee, le traitement du 
paquet au niveau du pont dit pont intermediate est different de celui d'un 
paquet ne comportant pas de troisieme zone. 

Selon une caracteristique, le procede comporte une etape de lecture 
des informations d'identification du chemin du paquet dans le reseau qui sont 
reparties dans la premiere et la au moins une troisieme zone. 

Les informations d'identification de chemin resultent en effet de la 
concatenation de plusieurs champs repartis dans plusieurs zones. 
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Selon une autre caracteristique, les informations d 'identification du 
chemin du paquet dans le reseau sont respectivement contenues dans deux 
champs d'informations concemant respectivement le chemin a parcourir et le 
chemin parcouru par ledit paquet de donnees et ayant chacun une longueur 
donnee, ledit procede comportant une etape de traitement desdites 
informations d'identification comportant notamment les etapes suivantes : 

- suppression d'au moins une premiere information d'un premier 
champ d'informations concernant le chemin a parcourir, r6duisant ainsi la 
longueur dudit premier champ d'informations d'une longueur correspondant a 
celle de ladite premiere information, 

- ajout d'au moins une deuxieme information dans un deuxieme 
champ d'informations concernant le chemin parcouru, augmentant ainsi la 
longueur dudit deuxieme champ d'informations d'une longueur correspondant a 
celle de ladite deuxieme information. 

Ce traitement est applique aux paquets de donnees regus par un 
pont, que ceux-ci comportent ou ne comportent pas de troisieme zone en plus 
de la premiere zone du paquet d'origine. 

Selon une caracteristique, le procede comporte, consecutivement a 
I'etape de traitement des informations d'identification du chemin dudit paquet 
de donnees dans le reseau, une etape d'ecriture desdites informations dans la 
premiere zone et ladite au moins une troisieme zone de ce paquet. 

Selon un troisieme aspect, I'invention vise un procede de 
traitement d'un paquet de donnees au niveau d'un pont d'un reseau de 
communication, ledit paquet de donnees comportant une premiere zone 
reservee au moins en partie a des informations dites d'identification d'un 
chemin pour ledit paquet de donnees dans ledit reseau et une deuxieme zone 
comportant des donnees dites utiles, caracterisS en ce que, ledit paquet de 
donnees comportant au moins une troisieme zone reservee au moins en partie 
a d'autres informations d'identification dudit chemin dans ledit reseau pour ledit 
paquet de donnees et qui competent lesdites informations d'identification de 
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ladite premiere zone pour constituer ledit chemin, ledit procede comporte les 
etapes suivantes : 

-lecture des informations d'identification du chemin du paquet 
dans le reseau qui sont reparties dans la premiere zone et la au moins une 
troisieme zone, 

-suppression de ladite au moins une troisieme zone dudit paquet. 

Correlativement, I'invention vise un dispositif de traitement d'un 
paquet de donnees au niveau d'un pont d'un reseau de communication, ledit 
paquet de donnees comportant une premiere zone reservee au moins en partie 
a des informations dites d'identification d'un chemin pour ledit paquet de 
donnees dans ledit reseau et une deuxieme zone comportant des donnees 
dites utiles, caracterise en ce que, ledit paquet de donnees comportant au 
moins une troisieme zone reservee au moins en partie a d'autres informations 
d'identification dudit chemin dans ledit reseau pour ledit paquet de donnees et 
qui completent lesdites informations d'identification de ladite premiere zone 
pour constituer ledit chemin, ledit dispositif comporte: 

-des moyens de lecture des informations d'identification du 
chemin du paquet dans le reseau qui sont reparties dans la premiere zone et la 
au moins une troisieme zone, 

- des moyens de suppression de ladite au moins une troisieme 
zone dudit paquet. 

Ainsi, apres avoir "desencapsule" le paquet d'origine comportant une 
premiere et une deuxieme zones, on recupere celui-ci au niveau d'un pont dit 
destination et ledit paquet est alors emis sur une partie (bus) du reseau a 
laquelle est connecte le pont et traite de fagon appropriee par un equipement 
ou peripherique destinataire connecte a cette meme partie (bus) du reseau. 

Selon un quatrieme aspect, I'invention vise un pont d'un reseau 
de communication interconnectant au moins deux parties dudit reseau de 
communication, caracterise en ce que ledit pont comporte un dispositif de 
traitement d'un paquet de donnees conforme a ce qui precede. 
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Selon un cinquieme aspect, I'invention vise un pont d'un reseau 
de communication interconnectant au moins deux parties dudit r6seau de 
communication, caracterise en ce qu'il comporte un dispositif de transfert d'un 
paquet de donnees comme expose ci-dessus. 
5 Selon un sixieme aspect, I'invention vise un appareil de traitement 

de donnees, caracterise en ce qu'il comporte un dispositif de traitement d'un 
paquet de donnees comme expos6 ci-dessus. 

Selon un septieme aspect, I'invention *vise un appareil de 
traitement de donnees, caracterise en ce qu'il comporte un dispositif de 
10 transfert d'un paquet de donnees conforme au bref expose qui precede. 

Selon un huitieme aspect, I'invention vise un appareil de 
traitement de donnees, caracteris6 en ce qu'il comporte un pont conforme a ce 
qui precede. 

L'appareil de traitement est, par exemple, une imprimante. 
1 5 L'appareil de traitement est, par exemple, un serveur. 

L'appareil de traitement est, par exemple, un ordinateur. 

L'appareil de traitement est, par exemple, un telecopieur. 

L'appareil de traitement est, par exemple, un scanner. 

L'appareil de traitement est, par exemple, un magneloscope. 
20 L'appareil de traitement est, par exemple, un decodeur (connu en 

terminologie anglo-saxonne sous le terme de "set top box"). 

L'appareil de traitement est, par exemple, un televiseur. 

L'appareil de traitement est, par exemple, un camescope. 

L'appareil de traitement est, par exemple, une camera numerique. 
25 L'appareil de traitement est, par exemple, un appareil 

photographique numerique. 

Selon un neuvieme aspect, I'invention vise un r6seau de 
communication comportant au moins deux parties interconnectees par au 
moins un pont, caracterise en ce que ledit pont est conforme a ce qui precede. 
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Selon un dixieme aspect, I'invention vise un r6seau de 
communication, caracterise en ce qu'ii comporte un appareil de traitement de 
donnees tel qu'expose ci-dessous. 

L'invention vise par ailleurs un moyen de stockage d'informations, 
eventuellement totalement ou partieliement amovible, lisible par un ordinateur 
ou un processeur contenant des instructions d'un programme informatique, 
caracterise en ce qu'il permet la mise en oeuvre du precede de transfert et/ou 
de traitement d'un paquet de donnees tel que brievement expose ci-dessus. 

L'invention vise en outre un moyen de stockage d'informations, 
eventuellement totalement ou partieliement amovible, lisible par un ordinateur 
ou un processeur contenant des donnees provenant de la mise en oeuvre du 
precede de transfert et/ou de traitement d'un paquet de donnees tel que 
brievement expose ci-dessus. 

L'invention vise egalement une interface permettant de recevoir 
les instructions d'un programme informatique, caracterise en ce qu'il permet la 
mise en oeuvre du precede de transfert et/ou de traitement d'un paquet de 
donnees tel que brievement expose ci-dessus. 

L'invention vise en outre un signal comportant des instructions 
utilisables par un ordinateur et adaptees a configurer un dispositif 
programmable en un dispositif de transfert et/ou de traitement d'un paquet de 
donnees tel qu'exposS ci-dessus. 

L'invention vise par ailleurs un signal comportant des instructions 
utilisables par un ordinateur et adaptees a faire fonctionner un dispositif 
programmable pour mettre en oeuvre un precede de transfert et/ou de 
traitement d'un paquet de donnees tel qu'expose ci-dessus. 

Les avantages et caracteristiques propres aux precedes et 
dispositifs de transfert et/ou de traitement, au pont interconnectant au moins 
deux parties d'un reseau et comportant de tels dispositifs, a I'appareil de 
traitement de donnees comportant de teis dispositifs, , a I'appareil de traitement 
de donnees comportant un tel pont, audit reseau comportant un tel pont et 
audit reseau comportant un tel appareil de traitement de donnees, ainsi qu'aux 
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moyens de stockage d'informations etant les mdmes'que ceux exposes ci- 
dessus concernant le precede de traitement d'un paquet de donnees faisant 
intervenir I'ajout d'une troisieme zone dans iedit paquet selon I'invention, ils ne 
seront pas rappeles ici. 

D'autres caracteristiques et avantages apparaftront au cours de la 
description qui va suivre donnee a titre d'exemple illustratif et non limitatif, et 
faite en reference aux dessins annexes sur lesquels : 

- la figure 1 est une vue schematique d.'un reseau de bus de 
communication seYie ; 

- la figure 2 est une vue schematique representant la structure 
d'un paquet de donnees asynchrone tel que defini dans la norme IEEE 1394- 
95; 

- la figure 3 est une vue schematique detaillee d'un appareil de 
traitement de donnees comportant un pont reference 66 sur la figure 1 ; 

- la figure 4 est une vue schematique representant differents 
registres stockes dans la memoire RAM de I'appareil de traitement de donnees 
de la figure 3 ; 

- la figure 5 est une vue schematique illustrant le transfert d'un 
paquet de donnees a travers le pont intermediate reference 66 la figure 1 ; 

- la figure 6 est une vue schematique illustrant le transfert d'un 
paquet de donnees a travers le pont destinataire reference 67 sur la figure 1 ; 

- la figure 7 est une vue schematique illustrant le transfert d'un 
paquet de donnees a travers le pont source reference 67 sur la figure 1 ; 

- la figure 8 est une vue schematique detaillee representant une 
table de routage stockee dans ia memoire RAM de I'appareil de traitement de 
donnees de la figure 3 ; 

- les figures 9 et 10 represented une vue schematique des 
algorithmes des precedes, d'une part, de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage et, d'autre part, de 
recuperation d'un index a partir d'un descripteur de chemin ; 
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- la figure 11 est une vue schematique de I'algorithme d'un 
precede de transfert de paquets ; 

- la figure 12 est une vue schematique d'un reseau de bus lors de 
la diffusion d'un paquet de resolution d'adresse d'une part, et de son paquet 
reponse correspondant d'autre part ; 

- la figure 13 est une vue schematique representant la structure 
d'un paquet de donnees de resolution d'adresse ; 

- la figure 14 est une vue schematique representant la structure 
d'un paquet de donnees asynchrone de reponse au paquet decrit en figure 13 ; 

- la figure 15 est une vue schematique detaiilee representant une 
table de verification stockee dans la memoire RAM de la figure 3 ; 

- la figure 16 est une vue schematique de I'algorithme d'un 
precede de reception d'un paquet de resolution d'adresse au niveau d'un 
equipement d'interconnexion d'un pont ; 

- la figure 17 est une vue schematique de I'algorithme d'un 
precede de reception d'un paquet de donn6es de reponse au paquet de 
resolution d'adresse au niveau d'un equipement d'interconnexion d'un pont ; 

- la figure 18 est une vue schematique de I'algorithme d'un 
precede de gestion de la longueur des identificateurs ou labels de routage au 
niveau d'un bus en fonction de la capacite du bus ; 

- la figure 19 est une vue schematique de I'algorithme d'un 
precede de gestion de la longueur des identificateurs ou labels de routage au 
niveau d'un bus en fonction du nombre de ponts connectes sur le bus. 

- la figure 20 est une vue schematique d'un r6seau de 
communication selon I'invention, 

- la figure 21 illustre de maniere schematique le m6canisme 
"d'encapsulation" selon I'invention, 

- la figure 22 represente un algorithme sur lequel est base le precede 
de transfert d'un paquet de donnees selon I'invention, et qui est mis en ceuvre 
au niveau d'un pont intermediate, 
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- la figure 23 represente deux etats (a) et (b) d'un registre de travail 

1598, 

-la figure 24 represente un algorithme sur lequel est base le procede 
de traitement d'un paquet de donnees selon I'invention, et qui est mis en oeuvre 
au niveau d'un pont source, 

- la figure 25 represente deux etats (a) et (b) d'un registre de travail 

1730, 

- la figure 26 illustre de maniere schematique le mecanisme de 
"desencapsulation" selon I'invention, 

- la figure 27 represente un algorithme sur lequel est base le proced<§ 
de traitement d'un paquet de donnees selon I'invention, et qui est mis en oeuvre 
au niveau d'un pont destination. 

La figure 1 represente une vue schematique d'un reseau de bus 
de communication s6rie dans le cadre duquel s'applique I'invention. Un 
ensemble de bus de communication serie 51, 52, 53, 54, 55, 56, 57, 58 et 59, 
interconnects par plusieurs ponts 60, 61, 62, 63, 64, 65, 66 et 67, permettent 
a des peripheriques situes sur des bus differents d'echanger des paquets de 
donnees asynchrones. 

Ainsi, un peripherique 68, connecte au bus 52, peut initier une 
transaction avec un peripherique 69 qui, lui, se trouve connecte au bus 59, par 
echanges de paquets asynchrones. Le transfert de paquets d'un bus a I'autre 
est assure par un procede de transfert de paquets. 

La structure d'un paquet asynchrone, largement decrite dans la 
norme IEEE 1394-95, est illustree a la figure 2. Les paquets asynchrones sont 
entre autre utilises pour effectuer des transactions entre un peripherique source 
et un peripherique destination. Une transaction est effectuee en emettant un 
paquet de type "Requete" de la source vers la destination, puis un paquet de 
type "Reponse" de la destination vers la source. 

Le champ "destinationJD" 80 de la figure 2 ("Destination 
Identifier" en terminologie anglo-saxonne), represente sur 16 bits, contient 
1'information de routage permettant d'atteindre le peripherique destination. Ce 
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champ est compose de deux sous champs 80a "destination_Bus_ID ,t 
represents sur 10 bits et 80b "destination_Node_ID" represents sur 6 bits. 

Le champ 80a est appelS champ d'identification du chemin a 
parcourir par le paquet de donnSes. 

Le champ "sourceJD" 81 ("Source Identifier" en terminologie 
anglo-saxonne), represents sur 16 bits, contient I'information de routage 
permettant d'atteindre le peripherique source. Ce champ est compose de deux 
sous champs 81a "source_Bus_ID" reprSsentS sur 10 bits et 81b 
"source_Node_ID" represents sur 6 bits. 

Le champ 81a est appelS champ d'identification du chemin 
parcouru par le paquet de donnSes. 

La prSsence de ces deux champs 80 et 81 favorise le 
dSroulement d'une transaction entre la source et la destination. 

II convient de noter que les deux champs d'informations 
d'identification d'un paquet de donnSes ne sont pas nScessairement placSs 
dans I'en-tete dudit paquet, comme c'est la cas dans cet exemple, mais 
peuvent etre situSs a I'extrSmitS opposSe de ce paquet, c'est-a-dire en fin de 
paquet. 

Le champ "tl" 82 ('Transaction Label" en terminologie anglo- 
saxonne), reprSsentS sur 6 bits, permet de numSroter une transaction entre des 
pSriphSriques. 

Le champ "rt" 83 ("Retry Code" en terminologie anglo-saxonne), 
reprSsentS sur 2 bits, permet d'identifier les tentatives d'emission d'un mSme 
paquet asynchrone. 

Le champ "tcode" 84 ("Transaction Code" en terminologie anglo- 
saxonne), reprSsentS sur 4 bits, permet d'identifier un type de paquet 
asynchrone, tel que par exemple le type de la transaction. 

Le champ "pri" 85 ("Priority" en terminologie anglo-saxonne), 
represents sur 4 bits, permet d'identifier la prioritS associSe au paquet 
asynchrone. 
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Les champs 86, 87, 88, 89 et 90 sont pour certains optionnels et 
sont relatifs a ('interpretation des donnees vehiculees par le paquet 
asynchrone. 

La figure 3 represents la structure schematique d'un appareil de 
traitement de donnees tel qu'un ordinateur 1 1 comportant, par exemple, le pont 
66 represents a la figure 1 . Ainsi, tous les ponts du reseau represents a la 
figure 1 ont par exemple cette structure. 

L'appareil de traitement de donnees pourrait egalement prendre la 
forme d'une imprimante, d'un serveur, d'un telecopieur, d'un scanner, d'un 
magnetoscope, d'un decodeur (connu en terminologie anglo-saxonne sous le 
terme de "set top box"), d'un televiseur, d'un camescope, d'une camera 
numerique ou d'un appareil photographique numerique. 

Tous les ponts de la figure 1 peuvent etre par exemple 6tre 
integres dans un appareil de traitement de donnees de ce type ou bien 
constituer l'appareil lui-meme. 

Le pont constitue, dans cet exemple, un dispositif de transfert de 
paquets. Ce pont comporte une unite de calcul CPU 12, une memoire de 
stockage permanent 14 (ROM) qui contient les differentes instructions des 
algorithmes represents aux figures 9, 10, 11, 16, 17, 18, 19, 23, 24 et une 
memoire de stockage temporaire 16 (RAM). Ces trois elements 12, 14 et 16 
communiquent au moyen de bus d'adresses et de donnees respectifs notes 18, 
20, 22, avec un bloc note 24 et connu de I'homme de I'art sous le nom de pont 
PCI. 

L'ordinateur 11 comporte egalement un ecran 13, un clavier 15, 
un lecteur de disquettes 17, un lecteur de CD-ROM 19 et une interface reseau 
21 (figure 3). 

L'interface reseau 21 peut recevoir, par exemple, par 
I'intermediaire d'un reseau local (non represent) de type Ethernet les 
instructions d'un programme informatique permettant la mise en ceuvre du 
procede selon I'invention. 
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De telles instructions peuvent egalement "etre contenues dans le 
lecteur de disquettes ou le lecteur de CD-ROM. 

Le bloc 24 est en fait un ensemble de composants PCI tel que 
I'ensemble Intel 440LX AGP ("Intel 440LX AGPset" dans la terminologie anglo- 
5 saxonne) commercialise par la societe INTEL. Ainsi, le bloc 24 comporte, par 
exemple, un composant 82443LX (non represente) qui assure I'interface avec 
la memoire 16 via le bus memoire 22 et avec I'unite de calcul CPU 12 via le bus 
local 18. Le composant 82443LX est lui-meme relie a un composant 82371 AB 
(non repr6sente) qui fournit une interface avec le bus ISA 20 relie a la memoire 
10 14 et aux differentes extensions de peripheriques : ecran 13, clavier 15, lecteur 
de disquette 17, lecteur de CD-ROM 19 et interface de reseau 21. Un 
controleur d'interruption IOAPIC Intel 82093AA (non represente) connecte a 
I'unite de calcul CPU 12 gere les interruptions pouvant survenir dans le 
systeme. 

1 5 Ce bloc 24 permet notamment d'echanger des donnees au moyen 

du bus standard PCI 26 (PCI signifiant en terminologie anglo-saxonne 
"Peripheral Component Interconnect") avec un autre composant d'interface PCI 
note 28. Le bus 26 peut egalement connecter entre eux d'autres elements, non 
represents sur la figure, eux-m§mes pourvus d'une interface PCI et pouvant 

20 mettre en ceuvre par exemple des fonctions de traitement de donnees. 

Le composant 28 est un composant denomme AMCC5933QC et 
est commercialise par la societe Applied Micro Circuits Corporation. 

II convient de noter que le dispositif de transfer* de paquets ne 
correspond pas necessairement au pont lui-m§me. II peut ainsi, en effet, en 

25 representor un sous-ensemble forme, par exemple, des differents elements 
permettant de mettre en ceuvre les fonctions de traitement de I'en-tete d'un 
paquet de donnees, de prise en compte d'au moins un identificateur de pont, et 
de transfert de paquets asynchrones. 

Les fonctions de traitement d'en-tete sont mises en ceuvre par 

30 I'unite de calcul CPU 12 et les memoires ROM 14 et RAM 16. 
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La fonction de transfert d'un paquet asynchrone apres traitement 
de I'en-tete est mise en ceuvre par un bloc logique de controle 34 et des 
composants 30, 32 sur ordre de I'unite de calcul CPU 12. 

Le pont 66 represents a la figure 3 comporte egalement deux 
ensembles de composants appeles aussi blocs 30 et 32 servant 
respectivement d'interfaces avec les bus de communication serie 1394, par 
exemple notes 56 et 58 sur la figure 1. Chaque bloc ou ensemble de 
composants PHY/LINK 1394 est par exemple constitue, d'un composant PHY 
TSB21LV03A et d'un composant LINK TSB12LV01A commercialises par la 
societe Texas Instruments et de connecteurs 1394, par exemple 
commercialises par la soctete Molex, par exemple sous la reference 53462. 

Le pont 66 comporte deux equipements d'interconnexion du pont 
qui ferment chacun ce que Ton appelle un "portal" en terminologie anglo- 
saxonne. 

Sur la figure 3 les elements du pont qui sont references 
12,14,16,18,20,22,24,26,28,34,36,38,40,42 et 44 sont communs a chacun des 
equipements d'interconnexion ou "portals" de ce pont et seuls les blocs de 
composants PHYLINK 1394 notes 30 et 32 sont specifiques respectivement a 
chaque equipement d'interconnexion. 

Toutefois, dans certains cas les equipements d'interconnexion ou 
"portals" d'un pont sont physiquement eloignes (cas d'une liaison radio) et les 
autres elements enonces ci-dessus sont alors propres a chacun des 
equipements d'interconnexion. 

Le bloc logique de controle note 34 peut respectivement 
communiquer avec les blocs de composants 30 et 32 au moyen de bus notes 
36 et 38, ainsi qu'avec le composant d'interface PCI 28 au moyen d'un bus 40. 

Des bus 42 et 44 permettent egalement les transferts de donnees 
respectivement entre le composant d'interface PCI 28 et le bloc logique de 
controle 34, ainsi que le bloc de composants PHY/LINK 1394 reference 30, 
d'une part, et, d'autre part, avec le bloc de controle logique 34 et le bloc de 
composants PHY/LINK 1394 reference 32. 
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Ce bloc logique de controle 34 permet de transmettre des paquets 
de donnees isochrones ou asynchrones venant du bus de communication s6rie 
56 par I'intermediaire du bloc de composants PHY/LINK 1394 note 30 qui lui 
est associe et a destination de la memoire RAM 16, sous le controle de la 
5 .fonction memoire a acces direct DMA ("Direct Memory Access" en terminologie 
anglo-saxonne) qui se trouve dans le composant d'interface PCI 28 et qui aura 
ete prealablement initialisee par ('unite de calcul CPU 12. 

Inversement, ce bloc 34 permet egalement de transmettre des 
paquets de donn6es isochrones ou asynchrones provenant de la memoire 16 

10 vers I'autre bloc PHY/LINK 1394 note 32, en vue de sa transmission sur le bus 
de communication serie qui lui est associe. Ceci a egalement lieu sous le. 
controle de la fonction memoire a acces direct DMA mentionn§ ci-dessus. 

Le bloc logique de controle 34 permet en outre de declencher une 
interruption PCI par exemple liee a la reception ou a remission d'un paquet 

15 asynchrone par I'intermediaire du composant d'interface PCI 28 afin d'informer 
I'unite de calcul CPU 12. De la meme maniere, le bloc logique de controle 34 
est susceptible de generer une interruption PCI pour d'autres types 
d'evenements tels que la reception ou remission de tout autre paquet de 
donnees sur un bus 1394. 

20 En outre, le bloc logique 34 permet d'acceder aux differents 

registres des blocs de composants 30 et 32 via le composant d'interface PCI 
28. 

Le bloc logique de controle 34 est un composant de type FPGA 
("Field Programmable Gate Array" en terminologie anglo-saxonne) qui est par 
25 exemple commercialise par la societe Xilinx. 

A chaque bloc de composants 30 et 32 sont associes des 
registres representee a la figure 4, utilises pour la mise en ceuvre du precede 
de transfer! de paquets de donnees. 

Dans la description qui suit, un registre dont le nom est suffix6 par 
30 "_30" ou "_32" appartient aux blocs respectifs 30 et 32 decrits precedemment 
en reference a la figure 3. 
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Un registre 91 dSnommS "routing_label_30", reprSsentS sur 8 bits, 
contient un identificateur ou adresse de routage qui identifie les paquets qui 
devront etre transfSrSs du bus 56 vers le bus 58 dans I'exemple du pont 66. 

Un registre 92 dSnommS "routing_width_30", reprSsentS sur 8 
5 bits, est associe au registre 91 et indique le nombre de bits significatifs du 
registre 91. Les registres 91 et 92 sont associes au bloc de composants 30. 

Un registre 93 denomme "routing_label_32", represents sur 8 bits, 
contient un identificateur ou adresse de routage qui identifie les paquets qui 
devront etre transferes du bus 58 vers le bus 56 dans I'exemple du pont 66. 
10 Un registre 94 denomme "routing_widthJ32 M , represents sur 8 

bits, est associe au registre 93 et indique le nombre de bits significatifs du 
registre 93. Les registres 93 et 94 sont associes au bloc de composants 32. 

Un registre 97 denomme "max_width", represents par exemple 
sur 32 bits, contient la valeur maximale que peuvent prendre les registres 92 et 
15 94. Ce registre n'est done pas associe a un Squipement d'interconnexion ou 
"portal" en particulier. A un instant donne, il contient la meme valeur dans 
chaque pont du reseau considers. 

Dans le mode prefers de realisation, la valeur des registres 92, 94 
et 97 est prSdSterminSe et Sgale a "3" pour chaque registre. 
20 Parmi I'ensemble des Squipements d'interconnexion ou "portals" 

connectSs a un mSme bus 1394 la norme P 1394.1 prSvoit la dStermination d'un 
Squipement d'interconnexion particulier appele "alpha-portal". 

Les moyens de determination de Talpha-portal" sont connus et 
notamment dScrits dans le chapitre 4.1 du projet de norme P1394.1 version 
25 0.04, du 7 FSvrier 1999. Ces moyens permettent notamment d'identifier de 
maniere constante et unique les pSriphSriques d'un meme bus. Par extension 
ces moyens permettent aussi d'affecter de la meme maniere un identificateur 
ou label de routage constant et unique a chaque Squipement d'interconnexion 
ou "portal" d'un meme bus. 
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II convient de noter que chaque equipement (pe>ipherique, 
equipement ^interconnexion...) relie a un bus est repere par un identificateur 
dit physique et par un identificateur dit virtuel. 

La correspondance entre I'identificateur physique et I'identificateur 
5 virtuel d'un equipement est etablie dans une table de correspondance telle que 
celle representee a la figure 21 et sur laquelle on reviendra plus en detail 
ulterieurement. 

La valeur de I'identificateur virtuel d'un Equipement connects a un 
bus reste constante meme si la topologie liee a ce bus est modifiee. 
10 Ainsi, vues de I'exterieur du bus, les valeurs des identificateurs 

virtuels ne changent pas malgrS une modification de la topologie du bus 
considered 

Par ailleurs, les 6quipements d'interconnexion relics a un bus 
possedent egalement I'identificateur de routage mentionne ci-dessus. 

15 Un identificateur de routage ainsi determine, par exemple pour 

I'equipement d'interconnexion du pont 66 qui est relie au bus 56, est stocke 
dans le registre 91 et identifie I'equipement d'interconnexion ou "portal" 
contenant le bloc 30 de la figure 3. De meme, un identificateur de routage ainsi 
determine, par exemple pour I'equipement d'interconnexion du pont 66 qui est 

20 relie au bus 58, est stocke dans le registre 93 et identifie I'equipement 
d'interconnexion ou "portal" contenant le bloc 32 de la figure 3. 

Un registre 95 denomme "routing_table_30" sur la figure 4, 
represente sur 960 bits, represente une table de routage associee a 
I'equipement d'interconnexion ou "portal" contenant le bloc 30 et est utilise lors 

25 du transfert de paquets emis depuis le bus 56, en ce qui concerne le pont 66. 

Un registre 96 denomme "routing_table_32", repr6sente sur 960 
bits, represente une table de routage associee a I'equipement d'interconnexion 
ou "portal" contenant le bloc 32 et est utilise lors du transfert de paquets emis 
depuis le bus 58, en ce qui concerne le pont 66. La structure de cette table de 

30 routage est decrite en detail a la figure 8. 
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Un registre 98 denomme "portal_numbering_30" sur la figure 4 
comporte, d'une part, au moins une table de correspond ance dont la structure 
sera decrite ulterieurement en reference a la figure 21 et qui est associee a 
5 I'equipement d'interconnexion ou "portal" contenant le bloc 30. 

Un registre 99 denomme "portal_numbering_32" sur la figure 4 
comporte, d'une part, au moins une table de correspondence dont fa structure 
sera decrite ulterieurement en reference a la figure 21 et qui est associee a 
10 I'equipement d'interconnexion ou "portal" contenant le bloc 32. 

Les registres 91, 92, 93, 94, 95, 96, 97, 98 et 99 represents a la 
figure 4, sont situes dans la memoire RAM 16 du pont 66 represents a la figure 
3. 

15 Un paquet asynchrone, emis par un peripherique source situe sur 

un bus different de celui sur lequel est situe le peripherique destinataire, est dit 

paquet asynchrone "distant", par opposition a un paquet asynchrone local. 

En outre, lorsqu'un paquet asynchrone "distant" transite, par 

exemple depuis le peripherique 68 (figure 1 ) jusqu'au peripherique 69, via les 
20 ponts 61, 62, 64, 66 et 67, differents traitements sont appliques par chacun de 

ces ponts en fonction de leur position relative par rapport au peripherique 

source et au peripherique destinataire. 

Ainsi, lorsqu'aucun des equipements d'interconnexion ou "portals" 

d'un pont considere n'est connecte ni au bus du p6ripherique source, ni au bus 
25 du peripherique destinataire, le pont est dit pont "intermediaire". C'est le cas du 

pont 66 lorsque, par exemple, le peripherique 68 transmet un paquet 

asynchrone au peripherique 69. 

La figure 5 illustre de maniere schematique le traitement, 

qu'effectue le pont 66 en tant que pont "intermediaire", sur les champs 80 et 81 
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du paquet asynchrone qu'il transfere depuis le bus 56 vers le bus 58, selon le 
sens indique par la fleche 219. 

Le registre 76 est I'equivalent du registre 91 represente a la figure 
4 et a, par exemple, pour valeur "001" en representation binaire sur 3 bits 
significatifs. 

En outre, le registre 77 est I'equivalent du registre 93 represente a 
la figure 4, et a, par exemple, pour valeur "01 1" en representation binaire sur 3 
bits significatifs. 

On va maintenant s'interesser, en reference aux figures 5 et 6, au 
transfer! d'un paquet asynchrone de donnees note 199 du bus 56 au 
peripherique 69 du bus 59. 

Le paquet asynchrone de donnees 199 transite sur le bus 56 et 
est transfere au bus 58, par le pont 66, apres traitement, sous la forme d'un 
paquet 216. Les paquets asynch rones 199 et 216 sont conformes a la structure 
de paquet representee a la figure 2 et ne different I'un de I'autre que par le 
contenu de leurs champs respectifs destination 80 et source 81. 

Le champ 80 du paquet 199 est decompose en plusieurs champs 
notes 200, 201, 202 et 203. Le champ 81 du paquet 199 est lui aussi 
decompose en plusieurs champs notes 204, 205, 206, 207 et 208. 

Les champs 201 et 202, tous les deux represents sur 3 bits, 
contiennent les identificateurs de routage des equipements d'interconnexion ou 
"portals" a prendre en compte respectivement par les ponts 66 et 67 pour 
transferer le paquet asynchrone jusqu'au peripherique destinataire 69. 

Les champs 208, 207 et 206, represents chacun sur 3 bits, 
contiennent les identificateurs de routage des equipements d'interconnexion ou 
"portals" a prendre en compte respectivement par les ponts 64, 62 et 61 pour 
transferer un paquet asynchrone en retour jusqu'au peripherique source 68. 

Le champ 203, represente sur 6 bits, contient ('information qui 
permet au pont 67 d'identifier le peripherique destinataire 69 du paquet 
asynchrone parmi tous les peripheriques du bus 59. De maniere generale, il 
s'agit du champ 80b "destination_Node_ID" de la figure 2. 
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Le champ 204, represents sur 6 bits, cbntient reformation qui 
permet au pont 61 d'identifier le peripherique source 68 du paquet asynchrone 
parmi tous les peripheriques du bus 52. De maniere generate, il s'agit du 
champ 81b "source_Node_ID" de la figure 2. 
.5 Les champs 200 et 205 dont I'ensemble est represente sur 5 bits 

qui sont tous positionnes a "1", contiennent un marqueur delimitant les champs 
202 et 201, d'une part, des champs 208, 207 et 206, d'autre part. 

Les champs 201 et 202 ferment ce que Ton appelle un premier 
champ d'informations et identifient le chemin qui est a parcourir par le paquet 
10 de donnees 199. 

Les champs 206, 207 et 208 ferment ce que I'on appelle un 
deuxieme champ d'informations et identifient le chemin deja parcouru par le 
paquet de donnees 199. 

Les champs 200 et 205 ferment ce que Ton appelle un troisieme 
15 champ d'informations ou marqueur. 

Dans le cas du paquet 216 issu du pont 66, le champ 80 
comprend les champs 209, 210, 211 et 203 et le champ 81 comprend les 
champs 212, 213, 214, 215 et 204. 

Le champ 211, represente sur 3 bits, contient I'identificateur de 
20 routage a prendre en compte par le pont 67 pour transferer le paquet 
asynchrone jusqu'au peripherique destinataire 69. II correspond au champ 201 
du paquet 199. 

Les champs 215, 214 et 213, represents chacun sur 3 bits, ainsi 
que les champs 209 et 212, dont I'ensemble est represente sur 3 bits, 
25 contiennent les identificateurs de routage a prendre en compte respectivement 
par les ponts 66, 64, 62 et 61, pour transferer le paquet asynchrone, en retour, 
jusqu'au peripherique source 68. Les champs 213 et 214 correspondent 
respectivement aux champs 207 et 208 du paquet 199. Les champs 209 et 212 
correspondent au champ 206 du paquet 199. 
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Le champ 210, represents sur 5 bits, qui' sont tous positionnes a 
"1", contient le marqueur delimitant le champ 211, d'une part, des champs 209 
a 215, d'autre part. II correspond aux champs 205 et 200 du paquet 199. 

A la reception du paquet 199, le pont 66 lit et analyse la valeur du 
5 champ 202 qu'il compare avec le contenu du registre 76. Puisque les deux 
valeurs, exprimees sur le meme nombre de bits significatifs, sont identiques, le 
paquet 199 va Stre transfere du bus 56 au bus 58 sous la forme du paquet 216. 

On notera qu'entre le paquet 199 et le paquet 216, le pont 66 a, 
d'une part, supprime du premier champ d'informations une premiere information 
10 constitute par les bits "001" appartenant au champ 202 et, d'autre part, ajoute 
au deuxieme champ d'informations une deuxieme information constitute par 
les bits "011" du registre 77 d'identification de i'tquipement d'interconnexion ou 
"portal" considered 

Sur la figure 5, il convient de noter que, d'une part, la suppression 
15 d'une premiere information (champ 202) du premier champ d'informations 
reduit la longueur de ce dernier et, d'autre part, I'ajout d'une deuxieme 
information (champ 215) dans le deuxieme champ d'informations augmente la 
longueur de ce dernier. 

Cette deuxieme information est representee par le champ 215. 
20 Le precede de transfer! de paquets precede egalement, apres la 

suppression de la premiere information et avant I'ajout de la deuxieme 
information, au decalage des premier, deuxieme et troisieme champs 
d'informations a I'interieurdes sous-champs 80a et 81a des champs 80 et 81. 

Lorsque Tun des equipements d'interconnexion ou "portals" d'un 
25 pont est connecte au bus du peripherique destinataire, le pont est dit pont 
"destination". C'est le cas par exemple du pont 67 de la figure 1 lorsque le 
peripherique 69 recoit un paquet asynchrone distant en provenance du 
peripherique 68. 

La figure 6 iilustre de maniere schematique le traitement, 
30 qu'effectue le pont 67 en tant que pont "destination", sur les champs 80 et 81 



27 



2794919 



du paquet asynchrone 216 qu'il transfere depuis le bus 58 vers le bus 59, selon 
le sens indique par la fleche 229. 

Le registre 78 illustre, pour le pont 67, le registre 91 represente a 
la figure 4 et dont la valeur, sur 3 bits significatifs, est "011" en representation 
binaire. Par ailleurs, le registre 79 illustre, pour le pont 67, un registre 93 
represente figure 4 et dont la valeur, sur 3 bits significatifs, est "000" en 
representation binaire. 

Le paquet asynchrone 216 qui transite suMe bus 58, est transmis 
sur le bus 59, par le pont 67 apres traitement, sous la forme d'un paquet 226. 
Les paquets asynchrones 216 et 226 sont conformes a la structure de paquet 
representee a la figure 2 et ne different I'un de I'autre que par le contenu de 
leurs champs respectifs 80 et 81 . 

Dans le cas du paquet 226, le champ 80 est decompose en 
plusieurs champs 220 et 221 et le champ 81 est lui aussi decompose en 
plusieurs champs 223, 224 et 204. 

Le champ 220, represente sur 10 bits qui sont tous positionnes a 
"1", est representatif d'un paquet asynchrone destine au bus local et 
susceptible d'etre recu par I'un des peripheriques du bus 59. 

Le champ denomme "offset" et note 223 est ajoute par le pont 67 
alors que le champ 224 contient I'identificateur de routage ou adresse de 
I'equipement d'interconnexion ou "portal" du pont 67 associe au bus 59 et 
stocke dans le registre 79. 

A la reception du paquet 216, le pont 67 lit et analyse la valeur du 
champ 211 qu'il compare avec le contenu du registre 78. Puisque les deux 
valeurs, exprimees sur le meme nombre de bits significatifs, sont identiques, le 
paquet 216 va etre transfere du bus 58 au bus 59 sous la forme du paquet 226. 

Lors du transfert du paquet 216 a travers le pont 67, ce dernier a 
supprime d'un premier champ d'informations qui est forme du champ 211, une 
premiere information constitute par les bits "01 1" du champ 211 lui-m§me. 

Ce premier champ d'informations identifie le chemin restant a 
parcourir au paquet 216 pour parvenir a destination. 
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Le pont 67 a ensuite sauvegarde dan's la table de routage 
associee a I'equipement d'interconnexion ou "portal" comprenant le registre 79 
un deuxieme champ d'informations qui est forme de ('ensemble des champs 
209,212, 213, 214 et 215. 
5 Ce deuxieme champ d'informations identifie je chemin parcouru 

par le paquet 216 et ce sera le chemin dit de "retour" qui lui permettra, 
eventuellement, d'etre renvoye au peripherique source. 

Le pont 67 a ensuite renseigne ce deuxieme champ 
d'informations alors forme par le champs 224, une deuxieme information 
10 constitute par les bits "000" du registre 79 d'identification de I'equipement 
d'interconnexion ou "portal" considere. 

Le troisieme champ d'informations correspond au marqueur note 
210 et precedemment evoque. 

Le precede de transfert de paquets precede egalement, apres la 
15 suppression de la premiere information et avant I'ajout de la deuxieme 
information, a la sauvegarde du deuxieme champ d'information, au stockage de 
I'index de cette sauvegarde dans le champ 223 et a la mise a "1" de tous les 
bits du champ 220.. 

Le champ 203, represents sur 6 bits, permet au pont "destination" 
20 67, d'identifier le peripherique destinataire 69 du paquet asynchrone parmi tous 
les peripheriques du bus 59. Le champ 203 du paquet 216 a ete remplace, lors 
du transfert dans le pont 67, par le champ 221 dans le paquet 226. Le champ 
221 identifie, par exemple, le peripherique 69 parmi tous les peripheriques du 
bus 59, afin que le paquet 226 soit recu par le peripherique 69. Le champ 203 
25 contient I'identificateur virtuel du peripherique 69 alors que le champ 221 
contient I'identificateur physique du peripherique 69 

Le champ 204, represents sur 6 bits, contient reformation qui 
permet au pont 61 d'identifier le peripherique source 68 emetteur du paquet 
asynchrone parmi tous les peripheriques du bus 52. Le champ 204 est 
30 representatif de I'identificateur virtuel du peripherique 68. 
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Lorsque l*un des Squipements d'interconnexion ou "portals" d'un 
pont est connecte au bus du peripherique source le pont est dit pont "source". 
C'est le cas par exemple du pont 67 de la figure 1 lorsque le peripherique 69 
transmet un paquet asynchrone "distant" a destination du peripherique 68, par 
5 exemple en reponse au paquet 226. 

La figure 7 illustre de maniere schematique les modifications 
effectuees par le pont 67 en tant que pont "source", sur les champs 80 et 81 
d'un paquet asynchrone qu'il transfere depuis le bus 59 vers le bus 58, selon le 
sens indique par la fleche 230. 
10 Le paquet asynchrone 231 emis sur le bus 59 par le pSriphSrique 

69 est transfer^ sur le bus 58, par le pont 67, apres traitement, sous la forme 
d'un paquet 240. Les paquets asynchrones 231 et 240 sont conformes a la 
structure de paquet representee a la figure 2 et ne different I'un de Tautre que 
par le contenu de leurs champs respectifs 80 et 81 . 
5 Dans le cas du paquet 231, le champ destination 80 est 

decompose en plusieurs champs 232, 233 et 234 et le champ source 81 est 
egalement decompose en plusieurs champs 235 et 236. 

Le champ denomme "offset" et note 232 est utilise par le pont 67 
pour retrouver I'ensemble des identificateurs de routage a prendre en compte, 
respectivement par les ponts 66, 64, 62 et 61, pour transferer le paquet 
asynchrone jusqu'au peripherique destinataire 68. Le champ 233 contient 
I'identificateur de routage du pont 67 associe au bus 59 et stocks dans le 
registre 79. 

Le champ 236, represents sur 10 bits, qui sont tous positionnes a 
"1", est representatif d'un paquet asynchrone emis par le bus local. 

Dans le cas du paquet 240, le champ destination 80 est 
decompose en plusieurs champs 241, 242, 243, 244 et 234 et le champ source 
81 est egalement decompose en plusieurs champs 246, 247, 248 et 249. 

Les champs 244, 243 et 242, represents chacun sur 3 bits, ainsi 
que les champs 241 et 246, dont I'ensemble est represents sur 3 bits, 
contiennent les identificateurs de routage ou adresses des Squipements 
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^interconnexion ou "portals" a prendre en compte respectivement par les ponts 
66, 64, 62 et 61, pour transferer le paquet asynchrone jusqu'au peripherique 
destination 68. 

Le champ 248, represents sur 3 bits, contient I'identificateur de 
5 routage a prendre en compte par le pont 67 pour transferer en retour le paquet 
asynchrone jusqu'au peripherique source 69. 

Le champ 247, represents sur 5 bits et dont tous les bits sont 
positionnes a "1", contient un marqueur delimitant les champs 241 a 244, 234 
et 246, d'une part, du champ 248, d'autre part. 

A la reception du paquet 231, le pont 67 lit et analyse la valeur du 
champ 233 qu'il compare avec le contenu du registre 79. Puisque les deux 
valeurs, exprimees sur le m§me nombre de bits significatifs, sont identiques, le 
paquet 231 va etre transfere du bus 59 au bus 58 sous la forme du paquet 240. 

On notera que dans le paquet 240, les identificateurs de routage 
241, 242, 243, 244 et 246 representatifs du chemin a parcourir jusqu'au 
peripherique destination 68 et le champ 248 representatif du chemin parcouru 
depuis le peripherique source 69 ont ete initialises par le pont 67 dans le 
paquet 240. 

Pour cela, le pont utilise la valeur stockee dans le champ "offset" 
232 du paquet 231 qu'il aura prealablement communique au peripherique 
source 69, par exemple, par I'intermediaire d'un paquet asynchrone 
precedemment recu. Ainsi, si, par exemple, le paquet 231 de la figure 7 
constitue la reponse du peripherique 69 au paquet recu 226 sur la figure 6, on 
notera que la valeur des champs 223 et 224 du paquet de donnees 226 est 
identique respectivement a la valeur des champs 232 et 233 du paquet 231 de 
la figure 7. 

On notera aussi que dans ce cas, la valeur des champs 209, 210, 
211 du paquet 216 de la figure 6 est respectivement egale a la valeur des 
champs 246, 247 et 248 du paquet 240 de la figure 7. De meme, la valeur des 
champs 212, 213, 214 et 215 du paquet 216 est egale respectivement a la 
valeur des champs 241, 242, 243 et 244 du paquet 240. 



31 



2794919 



Lors du transfert du paquet 231 a travers (e pont 67, ce dernier a 
insere le premier champ d'informations qui est forme des champs 244, 243, 
242, 241 et 246. Ce premier champ d'informations identifie le chemin restant a 
parcourir au paquet de donnees 231 pour parvenir a destination. 
5 Le pont 67 a ensuite ajoute dans un deuxieme champ 

d'informations, vide au pr§alab!e, une deuxieme information constitute par les 
bits "011" du registre 78 d'identification d'un equipement d'interconnexion ou 
"portal" considere. Cette deuxieme information est representee par le champ 
248. 

10 Ce deuxieme champ d'informations identifie le chemin parcouru 

par le paquet 231 depuis le peripherique 69 et ce sera le chemin d'informations 
dit de "retour" qui lui permettra, eventuellement, d'etre renvoye au peripherique 
source. 

Le troisieme champ d'informations correspond a une partie du 
15 champ 236 qui est transformee dans le paquet 240 en un champ 247 appele 
"marqueur". 

Le precede de transfert de paquets precede egalement, apres la 
suppression de la premiere information et avant I'ajout de la deuxieme 
information, a la lecture de la table de routage associee a Pequipement 

20 d'interconnexion du registre 79. 

Le contenu du champ 235, code sur 6 bits, est representatif de 
Tidentificateur physique du peripherique 69 parmi tous les peripheriques du bus 
59. Le champ 235 du paquet 231 a ete remplace par le champ 249 dans le 
paquet 240. La valeur du champ 249 , est quant a elle representative de 

25 Tidentificateur virtuel du peripherique 69 parmi tous les peripheriques du bus 
59. 

Le champ 234, code sur 6 bits, est representatif de Tidentificateur 
virtuel du peripherique destinataire 68 du paquet asynchrone parmi tous les 
peripheriques du bus 52. 
30 On notera que la valeur du champ 234 est egale a la valeur du 

champ 204 des figures 5 et 6. De meme, la valeur du champ 249 est egale a la 
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valeur du champ 203 des figures 5 et 6 et la valeur du champ 235 est egale a 
la valeur du champ 221 de la figure 6. 

Ainsi, on comprend que, lors du transfert d'un paquet par un pont 
intermediate, I'identificateur de routage de I'equipement d'interconnexion ou 
5 "portal" par lequel arrive le paquet est supprime du premier champ 
d'informations car il est devenu inutile et I'identificateur de routage de 
I'equipement d'interconnexion ou "portal" par lequel le paquet quitte le pont est 
ajoute dans un deuxieme champ d'informations afin de reconstruire le chemin 
parcouru par le paquet. 
10 Les deux identificateurs ayant la meme longueur, la longueur 

totale des premier, deuxieme et troisieme champs d'informations (figure 5) 
reste inchangee. 

En reduisant la longueur du premier champ et en augmentant la 
longueur du deuxieme champ au fur et a mesure du transfert du paquet par 
15 differents ponts du reseau on peut done augmenter la distance maximale 
parcourue par un paquet par rapport a I'art anterieur dans lequel la longueur de 
chaque champ destination et source reste fixe au cours du temps. 

II convient de remarquer que le troisieme champ ou marqueur a 
une longueur au moins egale au nombre de bits necessaire pour coder un 
20 identificateur de routage d'un equipement d'interconnexion ou "portal". 

Comme precedemment mentionne, le marqueur comporte une 
suite predeterminee de bits qui peut etre, par exemple, une suite consecutive 
de bits ayant tous un meme etat "0" ou"1". 

L'utilisation et la gestion du champ "offset" par les ponts source et 
25 destination sont plus particulierement decrites en reference aux figures 8, 9 et 
10. 

La figure 8 est une vue schematique detaillee d'une table de 
routage illustree par chaque registre 95, 96 de la figure 4 et qui est stockee 
dans la memoire RAM de chaque equipement d'interconnexion ou "portal" d'un 
30 pont source ou destination. Cette table a pour objectif d'associer a un index 
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("offset" en terminologie anglo-saxonne) unique sur ie bus local, un chemin 
permettant d'atteindre un peripherique distant et vice-versa. 

Cette table est composee d'un ensemble d'enregistrements 
elementaires 250 a 259, chaque enregistrement elementaire etant associe a un 
index dans la table. Les enregistrements 250, 251, 252, 253, 254, 255, 256, 
257, 258 et 259 sont respectivement associes aux index "0", "1", "2", "3", "4" 
"5", "6", "7", "8", "9". 

La structure d'un enregistrement elementaire est par exemple 
constitute des champs suivants. 

Le champ 270 "path_descriptor" correspond a un "descripteur de 
chemin", represents sur 16 bits et qui contient I'information de routage 
permettant d'atteindre le peripherique destinataire distant. 

Le champ 271 "activ" (raccourci de "activity", terminologie anglo- 
saxonne de "activite") represents sur 16 bits, contient I'information concernant 
la gestion au niveau du bus local dudit descripteur de chemin. 

Ce champ est notamment utilise pour connaitre, a un moment 
donne, combien de transactions de type "Requete" et "en attente de Reponse" 
sont en cours de traitement. 

Ce champ peut egalement etre utilise afin de connaitre depuis 
combien de temps I'enregistrement elementaire n'a pas ete consults. 

Pour ce faire, un compteur est increments suivant une periode 
predefinie par Pequipement d'interconnexion ou "portal" et est remis a zero a 
chaque utilisation de I'information "descripteur de chemin" ou de I'index. Ce 
champ permet ainsi d'optimiser la gestion de la memoire de la table de routage. 

II convient de noter que les index ("offsets") des enregistrements 
elementaires, non en cdurs d'utilisation et/ou n'ayant pas ete utilise depuis un 
certain temps, sont de preference reutilises en premier. 

Le champ 272 "local_bus_bit_map", represents sur 64 bits, 
permet de dScrire quels sont les peripheriques sur le bus local qui utilisent 
effectivement ce descripteur de chemin. Chacun des 64 bits, indexes de 0 a 63, 
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correspond au peripherique dont I'identificateur physique a pour valeur Tindex 
en question. 

Comme precedemment mentionne, ce champ permet d'optimiser 
la gestion de la memoire de la table, en evitant de reutiliser un index qui est 
5 utilise, meme peu souvent, par un nombre eleve de peripheriques. 

Ce champ presente surtout I'avantage de pouvoir determiner, 
dans le cas ou un index a ete attribue a un autre enregistrement elementaire, si 
I'index est toujours d'actualite pour un peripherique donne sur le bus local. 

La figure 8 decrit par exemple une table de routage pouvant 
1 0 contenir jusqu'a dix enregistrements elementaires qui sont alors indexes de 0 a 
9. Chaque enregistrement elementaire contient trois mots de 32 bits. La taiile 
maximale des enregistrements elementaires etant atteinte, une gestion de 
ceux-ci est necessaire afin d'en liberer avant de pouvoir en ajouter. 

On notera que la longueur des champs 270, 271 et 272 est 
indicative et peut etre reduite ou augmentee suivant les capacites du reseau. 

Ainsi, par exemple, si Ton autorise un maximum de 32 
peripheriques par bus, ceci incluant les ponts, la longueur du champ 272 
"local_bus_bit_map" peut etre reduite a 32 bits et le nombre total d'index peut 
etre augmente jusqu'a 15 pour une meme occupation de la memoire. 

Cette gestion peut obeir a differentes politiques comme par 
exemple celle selon laquelle les enregistrements elementaires non en cours 
d'utilisation et n'ayant pas ete utilise depuis une certaine duree sont Iiber6s. 

De meme, le nombre de peripheriques qui ont utilise et qui sont 
encore susceptibles d'utiliser un enregistrement elementaire donne peut 
avantageusement etre pris en compte. 

La figure 9 est une vue schematique de I'algorithme d'un precede 
de recuperation d'un descripteur de chemin a partir d'un index dans la table de 
routage decrite en figure 8. 

Ce procede est, par exemple, mis en ceuvre dans le pont 67 de la 
figure 7 lors du transfert du paquet 231 du bus 59 vers le bus 58. 
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Ces instructions ou etapes d'un tel procede sont stockees dans la 
memoire ROM du pont considere. 

Au cours d'une etape 301, le procede prevoit de recevoir une 
requete de recuperation d'un descripteur de chemin a partir d'un index donne. 

Au cours de I'etape 302, il est verifie que I'index en question se 
refere bien a un enregistrement elementaire dans la table de routage. Dans le 
cas positif, le traitement se poursuit par I'etape 303. Dans le cas negatif, le 
procede prevoit de retourner une information signifiant qu'aucun descripteur de 
chemin n'est valide pour ledit index (etape 305). 

Au cours de I'etape 303, le procede comporte une etape de 
verification selon laquelle I'enregistrement elementaire correspond bien a 
I'index presente par le peripherique a I'origine de la requite. II se peut en effet 
que I'enregistrement elementaire correspondant audit index ait ete supprime de 
la table, puis que cette valeur d'index ait ete reutilisee pour decrire un autre 
enregistrement elementaire pour un autre peripherique. 

Pour ce faire, un ensemble de 64 bits (indexes de 0 a 63) est 
utilise pour dresser une carte des peripheriques utilisant I'enregistrement 
elementaire en question. 

Chaque bit permet de savoir si, pour le peripherique dont 
I'identificateur physique a pour valeur I'index parmi les 64 bits, I'enregistrement 
elementaire est valide ou non. 

Dans le cas ou I'information est dite non valide, le procede prevoit 
de retourner une information signifiant qu'aucun descripteur de chemin n'est 
valide pour ledit index (etape 305). 

Dans le cas ou I'information est valide, I'etape 303 est suivie de 

I'etape 304. 

Au cours de I'etape 304, le procede effectue une lecture du 
descripteur de chemin, met a jour les informations de gestion relatives a 
I'enregistrement elementaire, et retourne finalement le descripteur de chemin 
pour ledit index. 
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Parmi les informations de gestion relatives a I'enregistrement 
elementaire, on peut notamment citer les deux actions suivantes : 

Premierement, quand une demande de recuperation d'un 
descripteur de chemin a partir d'un index est issue d'une transaction de type 
"Requete", un compteur indiquant I'usage de cet enregistrement elementaire 
est increments si une transaction de type "Reponse" est attendue. Ce compteur 
sera decrements lors d'une prochaine demande de recuperation d'un index a : 
partir d'un descripteur de chemin issue d'une transaction de type "Reponse". 

Deuxiemement, a chaque utilisation de I'enregistrement 
elementaire, le compteur indiquant la duree ecoulee depuis la derniere 
utilisation de cet enregistrement est remis a zero. 

Ce dernier compteur peut par exemple etre increments sur un 
evenement tempore! genere avec une periode predefinie. 

Apres avoir retourne le descripteur de chemin ou I'absence de 
descripteur de chemin pour ledit index, le precede prevoit de revenir a I'etape 
301 pour traiter toute nouvelle demande de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage. 

La figure 10 est une vue schematique de I'algorithme d'un 
precede de recuperation d'un index a partir d'un descripteur de chemin dans la 
table de routage decrite en figure 8. 

Ce precede est par exemple mis en oeuvre dans le pont 67 de la 
figure 6 lors du transfer! du paquet 216 du bus 58 vers le bus 59. 

Les instructions ou Stapes d'un tel procSdS sont stockees dans la 
memoire ROM du pont considers. 

Au cours d'une etape 311, le precede prevoit de recevoir une 
requete de recuperation d'un index a partir d'un descripteur de chemin donne. 

Au cours de I'etape suivante 312, le precede prevoit de verifier 
que le descripteur de chemin en question est present dans la table de routage. 

Dans le cas positif, I'etape 312 est suivie de I'etape 315, au cours 
de laquelle on met a jour, le cas echeant, les informations de gestion relatives a 
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I'enregistrement elementaire, et I'index correspondant audit descripteur de 
chemin est retourne\ 

Concernant les informations de gestion relatives a 
I'enregistrement elementaire, on peut notamment citer les deux actions 
suivantes : 

Premierement, quand une demande de recuperation d'un 
descripteur de chemin a partir d'un index est issue d'une transaction de type 
"Reponse", le compteur indiquant I'usage de cet ehregistrement elementaire 
est decr6mente. 

Deuxiemement, le compteur indiquant la duree ecoulee depuis la 
derniere utilisation de cet enregistrement est remis a zero. 

Ce dernier compteur peut par exemple etre increments sur un 
ev6nement tempore! genere avec une periode predefinie. 

Dans le cas negatif, le precede comporte une etape 313 au cours 
de laquelle il est verifie si au moins un index (et done un enregistrement 
elementaire) est libre dans la table de routage. 

Dans le cas positif, au cours d'une etape 314, un index est affecte 
et utilise pour stocker le descripteur de chemin d'informations. 

Un bit parmi I'ensemble des 64 bits (indexes de 0 a 63) qui 
correspond a I'identificateur physique du peripherique a I'origine de la 
demande, est positionne afin de valider cet enregistrement elementaire pour le 
peripherique en question. 

Si I'index n'est pas libre, le precede precede a la liberation d'un ou 
plusieurs index (et done d'enregistrement(s) elementaire(s)) dans la table de 
routage au cours d'une etape 316. 

L'etape suivante 317 consiste a verifier si l'etape de liberation a 
pu se faire avec succes. Dans le cas positif, l'etape 314 precedemment decrite 
est a nouveau effectuee. Dans le cas negatif, au cours d'une etape 318, le 
precede prevoit de retourner une information indiquant I'absence d'index (et 
done d'enregistrement elementaire) pour ledit descripteur de chemin. Ensuite, 
l'etape 31 1 est executee de nouveau. 
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La figure 11 represente un algorithme sur lequel est base un 
procede de routage des paquets asynchrones au niveau d'un pont. 

Les instructions ou etapes d'un tel procede sont stockees dans la 
memoire ROM de chaque pont. 

Cet algorithme concerne la prise de decision de routage desdits 
paquets ainsi que la transformation de leurs en-tetes, en fonction du resultat de 
I'analyse du contenu des en-tetes des paquets recus. 

Dans la suite de la description, des 1 variables temporaires 
stockees dans la memoire RAM du pont considere (D_BuslD, S_BuslD, in_RI, 
out_RI, path_register) ont ete introduites pour faciliter Ja comprehension de 
I'algorithme sur lequel est base le procede. 

Le procede debute par une etape notee 100 sur la figure 11 
consistant en I'attente de la reception d'un paquet asynchrone. Lorsqu'un tel 
paquet a ete recu et stocke en memoire, on passe a I'etape 401 d'analyse de 
ridentificateur du bus de destination D_BuslD compris dans I'en-tete dudit 
paquet. 

Dans la suite de la description, D_BuslD represente ('information 
du champ "destination_Bus_ID" de la figure 2, de meme S_BuslD represente 
['information du champ "source_Bus_ID" de cette mdme figure. 

Si ledit identificateur est egal a 3FF 16 , il s'agit alors soit d'un 
paquet emis sur le bus local et destine a ce bus local, soit d'un paquet distant 
arrive sur son bus de destination (comme decrit en figure 6). Dans ce cas 
d'egalite, I'etape 401 est suivie par I'etape 402 consistant, puisque ce paquet 
est destine audit bus local, a rejeter le paquet sans autre traitement. L'etape 
402 est suivie par I'etape 400 d'attente d'un nouveau paquet asynchrone. 

Lorsqu'au cours de I'etape 401 on trouve un identificateur du bus 
de destination different de 3FF 16 , cela signifie que le paquet est au niveau d'un 
pont intermediate et les etapes 403 et 404 sont alors executees. 

II convient de noter que, dans la suite de la description, selon le 
cas de figure envisage, I'information ou identificateur (ou label) de routage du 
descripteur de chemin de destination est lu dans les bits de poids faibles du 
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champ D_BuslD et I'information ou identificateur (ou label) de routage du 
descripteur de chemin parcouru est ecrit dans les bits de poids faibles du 
champ S_BuslD, les bits etant decales d'un champ a I'autre de facon 
appropriee. 

5 Par exemple, on precede a un decalage a droite du champ 

D_BuslD et a un decalage a gauche du champ S_BuslD, chaque bit issu du 
decalage a gauche du bit de poids fort du champ S_Bu'slD etant insere, apres 
decalage a droite des bits du champ D_BuslD , a la place du bit de poids fort 
du champ D_BuslD. 

10 D'autres variantes consistant a combiner lecture/ecriture des 

informations de routage des descripteurs de chemin sur les poids forts/faibles 
des champs D_BuslD et S_BuslD avec les decalages appropries ne sont pas 
decrites dans la presente description, mais peuvent etre envisagees par 
I'homme du metier. 

15 De retour a I'algorithme de la figure 11, I'etape 403 consiste a 

determiner I'identificateur ou label de routage du descripteur de chemin de 

destination in_RI. 

Pour ce faire I'identificateur ou label de routage est extrait du 

champ D_BuslD d'une longueur ou taille (en bits) egale au contenu du registre 
20 "routing_width_30" 92 (figure 4) associe a I'equipement d'interconnexion ou 

"portal" d'entree ("inbound portal" en terminologie anglo-saxonne). 

Dans I'exemple de la figure 5 , le champ D_BuslD vaut 

"1111 011 001 2 ", la valeur routing_width_30 est egale a 3 et I'identificateur ou 

label de routage in_RI est egal a 001 2 . 
25 Une fois la valeur de I'identificateur ou label de routage in_RI du 

paquet connue, I'etape 404 permet de la comparer au contenu du registre 

"routing_label_30" 91 qui constitue I'unique identificateur ou label de routage 

affecte pour le bus considere a I'equipement d'interconnexion ou "portal" sur 

lequel le paquet en question a ete recu. 
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Si les deux valeurs sont differentes, "alors I'etape 405 est 
executee. Cette etape consiste a rejeter le paquet puis a passer a I'etape 400 
decrite ci-dessus. 

Dans le cas contraire, c'est-a-dire lorsque les valeurs in Rl et 
5 routing Jabel_30 sont egales, I'etape 404 est suivie du test 406 afin d'analyser 
I'identificateur du bus source S_BuslD compris dans l'en-tete du paquet traite. 

Si I'identificateur est egal a 3FF 16 cela signifie que le paquet est 
situe au niveau d'un pont source, alors le paquet est dit "distant" (destinatafre 
sur un bus distant) et est recu de son bus source (comme par exemple le 
10 paquet reference 231 en figure 7). L'en-tete de ce paquet sera alors traite 
suivant les etapes 410, 411, 412, 413 ou 414 et 415 decrites de facon plus en 
detail ci-dessous. 

Dans le cas contraire, le paquet "distant" traite transite sur un bus 
intermediate entre son bus source et son bus de destination (comme par 
15 exemple le paquet reference 216 en figure 5). Le traitement de l'en-tete du 
paquet suit alors les etapes 420 et 421 egalement decrites ci-dessous. 

Pendant I'etape 410, on extrait du champ D_BuslD du paquet un 
index ("offset" en terminologie anglo-saxonne) de routage (precedemment 
defini lors de la description des figures 6 et 7) en tenant compte de la valeur 
20 routing_width_30 mentionnee ci-dessus lors de Implication de I'etape 403. Cet 
index ("offset") est constitue des (10 - routing_width_30) bits de poids forts du 
champ D_BuslD, 10 etant la largeur dudit champ D_BuslD. 

Par exemple, dans le cas ou le champ D_BuslD vaut 
"0001101 000 2 " et la valeur routing_width_30 est egale a 3, I'index sera egal a 
25 0001 101 2 . 

Ensuite, pendant I'etape 411, I'index ("offset") est converti en 
descripteur de chemin selon le precede de recuperation d'un descripteur de 
chemin a partir d'un index dans la table de routage, tel que decrit ci-dessus 
(figure 9, etapes 301 a 305). 
30 Un test 412 consiste alors a verifier si un tel descripteur de 

chemin a ete trouve au cours de Pexecution du precede. 
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Dans le cas negatif, on execute l'etape 413 consistant a rejeter le 

paquet traits. 

Dans des variantes de mise en oeuvre de ce procede, des 
methodes de traitement d'erreur plus sophistiquees (dont le detail n'est pas 
5 reproduit sur les figures) peuvent etre envisagees au cours de I'etape 413. 

De telles methodes consistent, par exemple, a envoyer un 
acquittement negatif au peripherique dont est issu le paquet pour lequef le 
descripteur de chemin est obsolete, permettant a celui-ci d'ajuster sa table de 
routage sans attendre I'expiration d'une certaine dur6e ("time-out" en 
10 terminologie anglo-saxonne). 

L'etape 413 est suivie par I'etape 400 d'attente d'un nouveau 
paquet a traiter deja d§crite ci-dessus. 

Dans le cas positif du test 412, le descripteur du chemin, retourne 
par I'etape 411, est stocks dans le registre "path_register" au cours de I'etape 
15 414. Le registre "path_register" est utilise pour la gestion des descripteurs de 
chemin (chemin destination et chemin parcouru) et est avantageusement 
compose de deux sous-champs, chacun de ces sous-champs correspondant 
aux informations respectivement contenues dans les champs D_BuslD et 
S_BuslD. 

20 Ensuite, au cours de I'etape 415, le procede effectue, sur le 

registre "path_register", le remplacement de I'identificateur physique du 
peripherique present dans le champ de I'adresse source 235 du paquet de la 
figure 7 par I'identificateur virtuel correspondant, ceci en utilisant une table de 
correspondence appropriee etablie lors de chaque reinitialisation ("bus reset" 

25 en terminologie anglo-saxonne) du bus source 52 de la figure 1 . Cette table 
etablissant la correspondance entre identificateurs physiques et virtuels des 
differents equipements (peripheriques, ponts, ...) connectes a un bus est bien 
connue de I'homme du metier et est d'ailleurs illustree a ia figure 21. 

L'etape 415 est alors suivie par une etape 430 dont la description 

30 est faite plus loin. 
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De retour a l'etape 406, si I'identificateur est different de 3FF 16 , 
alors cette etape est suivie d'une etape 420 de traitement d'un paquet recu a 
partir d'un bus intermediaire. 

L'etape 420 consiste a charger (memorisation) le registre 
H path_register" a partir des identificateurs de bus D_BuslD et S_BuslD extraits 
respectivement des champs "sourceJD" 81 et "destinationJD" 80 de I'en-tete 
(figure 2) du paquet traite. 

On rappelle ici que chacun des deux identificateurs du bus est 
constitu6 des 10 bits de poids fort du champ d'adresse correspondant (80 ou 
81), tandis que les 6 bits restants desdits champs d'adresse represented 
I'identificateur (soit physique, soit virtuel) du peripherique adresse sur le bus 
donne. 

(.'operation de chargement tient compte du mode de gestion des 
champs D_BuslD et S_BuslD mentionne precedemment comme, par exemple, 
le decalage a droite du champ D_BuslD et le decalage a gauche du champ 
S_BuslD, et ou chaque bit issu du decalage a gauche du bit de poids fort du 
champ S_BuslD est insere, apres decalage a droite des bits du champ 
D_BuslD, a la place du bit de poids fort du champ D_BuslD. 

Ensuite, au cours de l'etape 421, le contenu du registre 
"path_register" est transforme de la facon indiquee ci-apres (pour une meilleure 
comprehension de cette etape, le lecteur est prie de se referer a la figure 5). 

On repere tout d'abord une sequence de longueur maximale 
comportant au moins (2 max_width - 1) bits consecutifs a "1" (max_width etant 
la valeur du registre 97 de la figure 4) constituant un marqueur ou separateur 
entre le champ identifiant le chemin de destination et le champ identifiant le 
chemin parcouru. Dans I'exemple du paquet 199 illustre a la figure 5, la 
sequence comporte 5 bits a "1", la sequence "011 001 2 " decrit le chemin de 
destination, et la sequence "01 1 010 01 1 2 " decrit le chemin parcouru. 

II convient de noter ici qu'en separant les trois champs cites de la 
maniere precedemment decrite, on peut attribuer (de facon erronee) au 
marqueur d'eventuels bits adjacents appartenant au champ du chemin 
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parcouru et/ou au champ du chemin de destination dans le cas ou lesdits bits 
sont egaux a "1". Ceci ne constitue toutefois pas un probleme pour le 
fonctionnement correct de I'algorithme decrit. 

On effectue ensuite un decalage dans le registre "path_register", 
selon le mode de gestion adopte, des bits du champ descripteur du chemin de 
destination (identificateur du chemin a parcourir) d'un nombre de bits qui est 
egal a la valeur routing_width_30. . ~ 

Les bits non significatifs, suite au decalage, se trouvent 
positionnes a "1" et les bits du marqueur ne sont pas modifies. Le registre 
"routing_width_30" 92 indique la longueur en bits de I'identificateur ou label de 
routage sur le bus d'entree du paquet traite. 

Ainsi, dans I'exemple de" la figure 5, les bits du champ 202 ont 
disparu, les bits du champ 201 ont ete decale d'un nombre de bits egal a la 
valeur routing_width_30 (a droite dans le champ "destination_Bus_ID" 80a de 
la figure 2) et occupent maintenant le champ reference 211, les bits devenus 
non significatifs du champ reference 201 sont mis a "1", les bits du marqueur, 
reference par les champs 200 et 205 restant inchanges. 

II convient de noter que la taille ou longueur en bits du marqueur 
se trouve ainsi augmentee d'un nombre egal a la valeur routing_width_30. 

On effectue alors un decalage dans le registre "path_register", 
selon le mode de gestion adopte, des bits du marqueur du chemin parcouru 
(identificateur du chemin parcouru) d'un nombre de bits qui est egal a la valeur 
routing_width_32, un nombre de bits egal a la valeur routing__width_32 des bits 
du marqueur se trouvant alors ecrit. 

Rappelons ici que le registre "routing_width_32" 94 assocte a 
I'equipement d'interconnexion ou "portal" de sortie ("outbound portal" en 
terminologie anglo-saxonne) indique en fait la longueur en bits de 
I'identificateur ou label de routage sur le bus de sortie du paquet traite. 

La valeur des bits decrivant I'identificateur ou label de routage 
pour le descripteur du chemin parcouru (identificateur du chemin parcouru) 
sera determinee pendant I'etape 450 executee ulterieurement. 
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Dans I'exemple de la figure 5, les bits d'informations des champs 
206, 207 et 208, decrivant le chemin parcouru, ont ete decale d'un nombre de 
bits egal a la valeur routing_width_32 (a gauche dans le champ 
"source_Bus_ID" 81a de la figure 2 puis a droite dans le champ 
"destination_Bus_ID" 80a de la figure 2) et occupent alors respectivement les 
champs 209 et 212 pour le premier, 213 pour le second et 214 pour le 
troisieme. Les champs 209 et 212 faisant auparavant partie du marqueur 
contiennent desormais des informations decrivant le 1 chemin parcouru. Le 
champ 215 va etre affecte lors de I'operation decrite a I'etape 450. 

Lors des differentes phases mentionnees ci-dessus et qui ont lieu 
au cours de I'etape 421, le marqueur s'est egalement trouve deplace par 
rapport a sa position anterieure a I'interieur du registre "path_register". 

Si la valeur routing_width_32 est superieure 3 la valeur 
routing_width_30, alors la longueur du marqueur est reduite de la difference. 

De facon similaire, si la valeur routing_width_32 est inferieure a la 
valeur routing_width_30, alors la longueur du marqueur est augmentee de la 
difference. 

II convient de noter qu'en suivant cette regie, la longueur du 
marqueur reste superieure ou egale a la valeur 4*max_width - 1 - 
routing_width_30 - routing_width_32 (qui est toujours superieure ou egale a 
2*max_width - 1) dans chaque pont traverse a condition que cette condition soit 
remplie initialement. 

Ceci garantit que le marqueur reste identifiable par chaque pont. 
Dans I'exemple de la figure 5, le marqueur ou champ separateur auparavant 
constitue des champs 200 et 205, se trouve, apres passage du pont 66, 
represents par le champ 210, sa longueur etant restee de 5 bits. 

Dans la presente description, la taille ou longueur des 
identificateurs ou labels de routage est fixe dans tout le reseau bien que cela 
ne soit pas imperatif. Ceci implique que les registres "routing_width_30" 92, 
"routing_width_32" 94 et "max_width" 97 component la meme valeur dans 
chaque pont du reseau. On notera que, pour ce faire, il suffit que le marqueur 
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comporte au moins un nombre de bits egal a la valeur "max_width" (au lieu de 
2*max_width - 1 bits dans i'hypothese d'une longueur variable des 
identificateurs ou labels de routage). 

Dans une variante de realisation, les registres "routing_width_30" 
5 92, "routing_width_32" 94 peuvent comporter des valeurs differentes pour un 
meme pont du reseau. 

On notera que la description faite en reference a la figure 1 et qui 
precede s'applique a cette variante. 

L'etape 421 est suivie par les etapes 430 de lecture du champ 
10 .compose des (routing_width_32) bits du premier champ (equivalent de 
D_BuslD) du registre "pathjegister" et par le test 431 afin de determiner si 
tous les bits lus sont egaux a "1", c'est-a-dire si le paquet est arrive sur son bus 
de destination. Dans ('affirmative, les etapes 440, 441, 442 et 443 sont 
executees, sinon on passe aux etapes 450 et 451 . 
15 Pour une meilleure comprehension de la description des etapes 

440 a 443 du traitement d'un paquet arrivant sur son bus de destination 59, le 
lecteur est prie de se referer a la figure 6. 

Lors de l'etape 440, le champ 203 de I'en-tete du paquet 
asynchrone constituant I'identificateur virtue! du peripherique ou equipement 69 
20 destinataire dudit paquet sur le bus 59 est remplace par I'identificateur 
physique 221 qui lui correspond en utilisant la table de correspondance 
appropriee. 

L'etape 441 consiste a convertir I'identificateur du chemin 
parcouru contenu dans le registre "path_register" en index 223 ("offset") 
25 comme decrit ci-dessus en reference aux etapes 31 1 a 318 de la figure 10. 

Au cours de l'etape 442, le champ de I'en-tete identifiant le 
chemin parcouru est initialise avec la concatenation dudit index 223 ("offset") et 
du contenu 224 du registre "routing_label_32" 93 (figure 4) en tenant compte 
du nombre des bits valides de I'identificateur ou label de routage, indique par le 
30 registre "routing_width_32" 94. 
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Ensuite, au cours de I'etape 443, le champ de I'en-tete 220 
identifiant le bus de destination est initialise avec la valeur 3FF 16 . Ce traitement 
est suivi par I'etape 460. 

Au cours de I'etape 450 (lorsque les bits lus ne sont pas tous 
egaux a "1"), les bits identifiant le chemin parcouru du registre "pathj-egister" 
(nombre indique par la valeur routing_width_32) sont initialises avec 
I'identificateur ou label de routage 93 stocke dans le registre "routing_label_32" 
associe a I'equipement d'interconnexion ou "portal" situq sur le bus de sortie du 
paquet traite. 

Pendant I'etape 451 les champs identifiant le bus source, c'est-a- 
dire les champs 212, 213, 214, 215, 209 et le bus de destination, c'est-a-dire 
les champs 210 et 211 sont respectivement initialises avec le contenu du 
registre "path_register". Ce traitement est egalement suivi par I'etape 460. 

L'etape 460 consiste a transferer le paquet sur le bus 58 (figure 
7), respectivement 59 (figure 6). Cette etape est suivie par I'etape 400 d'attente 
d'un nouveau paquet a traiter. 

La figure 12 est une vue schematique d'un reseau de bus lors de 
la diffusion d'un paquet de resolution d'adresse d'une part, et de son paquet 
reponse correspondant d'autre part. 

Ce reseau est compose des bus 501 a 505 interconnects par les 
ponts 506 a 511. 

Le paquet de resolution d'adresse est envoye par un equipement 
source 513 afin d'obtenir un descripteur de chemin permettant ensuite 
d'acceder a I'equipement distant au moyen de paquets asynchrones tels que 
decrits dans le standard 1394-95. Ce paquet de resolution d'adresse est diffuse 
dans tout le reseau de bus ("broadcast" en terminologie anglo-saxonne). 

Un mecanisme complementaire peut etre mis en oeuvre au niveau 
de chaque equipement d'interconnexion ou "portal" d'un pont pour eviter que le 
paquet ne soit transmis plus d'une fois sur le meme bus et ainsi eviter tout 
bouclage infini dans le reseau de bus. Ce mecanisme, connu de I'homme du 
metier et decrit par exemple dans le livre "DATA NETWORKS, second edition, 
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by Bertsekas Gallager, Prentice Hall International Editions, ISBN 0-13-201674- 
5" dans le chapitre intitule "Flooding and broacasting", s'appuie par exemple 
sur les principes suivants : le paquet en cours de diffusion est identify de facon 
unique (par exemple a I'aide d'un num6ro d'identification unique qui est le 
numero EUI-64 de I'equipement source et d'un num6ro de sequence identifiant 
ce paquet de maniere unique dans ce meme equipement source), quand un 
equipement d'interconnexion ou "portal" diffuse ce paquet, il memorise 
certaines d'informations qui lui permettront ensuite de savoir si un paquet de 
diffusion qu'il a recu doit ou ne doit pas etre diffuse sur I'autre equipement 
d'interconnexion ou "portal" du pont consider^, le cas echeant sur chacun des 
autres equipements d'interconnexion ou "portals" dudit pont, notamment en 
fonction d'une pr6c6dente reception de ce m§me paquet. 

Les equipements d'interconnexion ou "portals" doivent, entre 
autre, a cette fin gerer une table de verification dite de "diffusion" comme par 
exemple celle decrite a la figure 15. 

Dans le cas ou ce paquet doit etre diffuse sur un bus, 
I'equipement d'interconnexion ou "portal" en question met a jour le descripteur 
de chemin qui permettra de diriger (router) directement le paquet reponse vers 
I'equipement qui est a I'origine du paquet de resolution d'adresse. La diffusion 
de ce paquet de resolution d'adresse est indiquee sur la figure 12 par les 
fleches 520, 521, 522 et 523. 

Lorsque chaque equipement d'interconnexion ou "portal" d'un 
m§me pont est regroupe dans un seul et meme dispositif tel que celui 
represents a la figure 3, une seule table de verification dite de "diffusion" 
commune peut etre utilisee pour tous les equipements d'interconnexion ou 
"portals" d'un pont donne. 

Sur un bus donne, chaque equipement d'interconnexion ou 
"portal", possedant en interne une table des numeros EUI-64 des differents 
equipements connectes sur le bus, est en charge de verifier, a la reception d'un 
paquet de resolution d'adresse, si I'equipement recherche est present ou non 
sur le bus. 
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Dans le cas positif, I'equipement ^interconnexion ou "portal" du 
pont 506 par exemple celui connects au bus 501 stoppe la diffusion du paquet 
de resolution d'adresse et emet un paquet de donnees asynchrone de reponse 
530 vers le pont 508 qui transfere cette reponse sous la forme d'un paquet 531 
au pont 510, a destination de I'equipement qui est a I'origine du paquet de 
resolution d'adresse. 

Pour ce faire I'equipement d'interconnexion ou "portal" recupere 
dans le paquet de resolution d'adresse le descripteur de chemin mis a jour lors 
de la diffusion. 

Le paquet de donnees asynchrone de reponse faisant route vers 
I'equipement 513 a I'origine du paquet de resolution d'adresse va construire le 
descripteur de chemin recherche. II en est de meme pour I'equipement 
d'interconnexion ou "portal" du pont 507 qui va emettre un paquet de donnees 
asynchrone de reponse 533 vers le pont 510 (figure 12). 

II appartient a chaque equipement d'interconnexion ou "portal" 
des ponts du bus 504 , ou se situe I'equipement 513 a I'origine du paquet de 
resolution d'adresse, de reconnaitre les differents paquets de donnees 
asynchrones de reponse, de les filtrer et de n'en envoyer qu'un seul, reference 
534 sur la figure 12, vers I'equipement 513, dans le cas ou celui-ci ne viendrait 
pas deja d'un autre equipement d'interconnexion ou "portal" relie au bus 504. 

Pour ce faire, I'equipement d'interconnexion ou "portal" doit 
memoriser le fait que la requete de resolution d'adresse a ete suivie d'une 
reponse, par exemple en sauvegardant a partir de la premiere reponse recue, 
et ce pendant une certaine duree, des donnees comme le numero EUI-64 de 
I'equipement recherche et le numero de sequence identifiant le paquet de 
resolution d'adresse de maniere unique dans cet equipement source, et en les 
comparant avec celles effectivement regues dans les autres paquets reponses. 
Les eventuels paquets de donnees asynchrones de reponse s'averant etre des 
doublons sont simplement ignores. 

La figure 13 est une vue schematique representant la structure 
d'un paquet de donnees de resolution d'adresse 550. Ce format de paquet est 
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preferentiellement base sur le format d'un paquet global' de flux asynchrone (en 
terminologie anglo-saxonne "Global Asynchronous Stream Packet" ou en 
abrege "GASP"). 

Les champs 551 a 556 denommes "datajength", "tag", channel", 
"A 16 ", "sy" et "header_CRC" ont des valeurs constantes definies par le comite 
de normalisation 1394. 

La valeur du champ 557 "sourceJD" permet de specifier I'adresse 
de I'equipement d'interconnexion ou "portal" emetteur du paquet. 

Les champs 558 a 560 denommes "specifiier_ID_hi", 
"specifiierJDJo", et "version" ont des valeurs constantes definies par le comite 
de normalisation 1394. 

Les champs 561 a 568 constituent une partie denommee "champ 
de donnees" ("data field" en terminologie anglo-saxonne) d'un paquet GASP et 
sont utilises de la facon indiquee ci-apres. 

Le champ descripteur de chemin 561 ("path_descriptor" en 
terminologie anglo-saxonne), represents sur 20 bits, contient I'information de 
routage elaboree lors du cheminement du paquet de resolution d'adresse vers 
I'equipement destination recherche. La valeur de ce champ est done 
representative du chemin parcouru. La taille utile de ce champ est definie a 
partir de la valeur des champs "max_width" 97, "routing_width_30" 92, et 
"routing_width_32" 94 (figure 4) et des traitements effectues sur le chemin 
parcouru tels qu'explicites lors de la description de I'etape 421 de la figure 11. 
Par exemple, lorsqu'un paquet de resolution d'adresse present sur le bus 56 de 
la figure 1 est susceptible d'etre transfere par le pont 66 sur le bus 58 et que le 
champ 561 comporte, par exemple, les champs 200 et 205 a 208 de la figure 5, 
alors le contenu du champ 561 sera remplace par les champs 210, 209 et 212 
a 215 lors du transfert via le pont 66. 

Le champ denomme "sequence_number" ("numero de 
sequence") et note 562, represents sur 12 bits, permet d'identifier ce paquet de 
maniere unique dans I'equipement source a I'origine de la requete de resolution 
d'adresse. 
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Les champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo H 
("EUI-64 source haut et bas") et notes respectivement 563 et 564, represents 
chacun sur 32 bits, decrivent le numeYo EUI-64 de I'equipement a I'origine de 
ce paquet de resolution d'adresse. Ce numero EUI-64 est utile pour identifier 
de maniere unique I'equipement source a I'origine de la requete de resolution 
d'adresse. 

Les champs denommes "Dev_EUI_64_hi" et "Dev_EUI_64_lo" 
("EUI-64 equipement recherche haut et bas") et notes, respectivement 565 et 
566, represents chacun sur 32 bits, decrivent le numero EUI-64 de 
I'equipement recherche par I'equipement a I'origine de ce paquet de resolution 
d'adresse. Ce num6ro EUI-64 identifie de maniere unique I'equipement 
recherche. 

Quand un equipement souhaite communiquer avec un 
equipement distant, celui-ci positionne, entre autres, les champs 563 et 564 
("Src_EUI_64_hi" et "Src_EUI_64Jo") avec son numero EUI-64, et le champ 
numero de sequence 562 avec une valeur unique pour cet equipement (valeur 
incrementee, par exemple, apres chaque emission d'un tel paquet). 

En sauvegardant, pendant une duree predetermine par exemple 
egale a une seconde, ce numero de sequence pour chaque equipement 
6metteur d'un paquet de resolution d'adresse, chaque 6quipement 
d'interconnexion ou "portal" du reseau peut ainsi eviter d'emettre a nouveau ce 
paquet sur le(s) bus adjacent(s). 

Le champ denomme "response packet type specific information" 
("information specifique pour le paquet reponse") et note 567, represent sur 
48 bits, contient Information necessaire pour construire le paquet reponse en 
reponse au paquet de resolution d'adresse. Cette information est positionnee 
par I'equipement emetteur du paquet de resolution d'adresse. Ce champ 
specifie notamment, dans le cas ou le paquet reponse est base, par exemple, 
sur un paquet primaire asynchrone ("asynchronous primary packet" en 
terminologie anglo-saxonne) de type ecriture (decrit dans la norme 1394-95), 
I'adresse de destination dans I'equipement source qui est a I'origine du paquet 
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de resolution d'adresse, adresse a laquelle I'equipement destinataire recherche 
pourra 6crire des donnees en reponse a la requete. Le paquet de reponse est 
par exemple un paquet de type requete d'ecriture d'un bloc de donnees ("write 
request for data block" en terminologie anglo-saxonne). 

Un champ denomme "reserved" ("reserve") et note 568, 
represents sur 16 bits, comme son nom I'indique, n'est pas utilise pour I'instant. 

La valeur d'un champ denomme "data_CRC" et note 569 est 
calculee en fonction de la valeur des champs 557 a* 568 selon des regies 
predeterminees par le comite de normalisation 1394. 

La figure 14 est une vue. schematique representant la structure 
d'un paquet de donnees asynchrone 580 de reponse au paquet de resolution 
d'adresse 550 decrit precedemment. Le format d'un tel paquet est largement 
decrit dans le standard 1394-95 et est illustre en figure 2. Seuls les champs 
utiles dans le cadre du present document sont decrits ci-apres. 

Comme if a ete mentionne precedemment, la valeur d'un champ 
denomme "tCode" et note 585 peut par exemple correspondre a une requete 
du type "write request for data block". 

Un champ denomme "reserved" ("reserve") et note 590, 
represents sur 16 bits, comme son nom I'indique, n'est pas utilise pour I'instant. 

Un champ denomme "sequence_number" ("numero de 
sequence") et note 591, represents sur 12 bits, permet d'identifier le paquet de 
maniere unique dans I'equipement qui est a I'origine de la requete de resolution 
d'adresse. 

Des champs denommes "Src_EUI_64_hi" et "Src_EUI_64_lo H 
("EUI-64 source haut et bas") et notes respectivement 592 et 593, represents 
chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement a I'origine du 
paquet de resolution d'adresse. Ce numero EUI-64 est utile pour identifier de 
maniere unique I'equipement qui est a I'origine de la requete de resolution 
d'adresse. 

Les champs 592, 593 ("Src_EUI_64_hi" et "Src_EUI_64_lo") et le 
champ 591 ("sequence_number") permettent notamment a chaque Squipement 
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^interconnexion ou "portal" sur le bus dit "source" (bus ou se situe 
I'equipement qui est a I'origine de la requete de resolution d'adresse) de savoir 
si une reponse a deja ete envoyee a I'equipement qui est a I'origine de la 
requete de resolution d'adresse. 

Les equipements d'interconnexion ou "portals" sur le bus "source" 
doivent pour cela gerer une table de verification dite de "reponse" comme par 
exemple celle decrite en figure 15. 

On notera que la detection et le traitement du bouclage ("loop 
detection" en terminologie anglo-saxonne) concerne une amelioration apportee 
au procede de routage d'un paquet de resolution d'adresse et qui utilise des 
proced6s decrits dans I'etat de Cart. 

En effet, un traitement par defaut du bouclage est mis en oeuvre 
par le procede de routage d'un paquet de resolution d'adresse lors du 
traitement associe au champ 561 : lorsque la totalite de la zone utile du champ 
561 du paquet de resolution d'adresse est utilisee pour decrire le chemin 
parcouru, le procede de transfert du paquet d'un bus a I'autre est stoppe. 

Ainsi, le procede de transfert de paquet va consommer, par 
insertion d'identificateurs ou labels de routage lors de chaque boucle, une 
partie de la zone utile du champ 561 du paquet de resolution d'adresse, jusqu'a 
remplir la totalite du champ, ce qui a pour effet de mettre fin au transfert du 
paquet. 

La figure 15 est une vue schematique detaillde representant une 
table de verification 600 stockee dans la memoire RAM de la figure 3. Ce type 
de table peut etre utilise par les deux types de verification precedemment 
decrits : 

- diffusion d'un paquet de resolution d'adresse d'une part, 

- generation d'un seul et unique paquet de reponse correspondant 
a un paquet de resolution d'adresse sur le bus ou se situe I'equipement qui est 
a I'origine de ce paquet de resolution d'adresse. 

La figure 15 illustre par exemple une table de verification 
contenant un nombre limite d'enregistrements elementaires notes 601 a 605. 
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Des champs denommes "Src_EUI_64_hi" et "Src_EUI_64Jo" 
("EUI-64 source haut et bas") et notes respectivement 610 et 611, repr6sentes 
chacun sur 32 bits, decrivent le numero EUI-64 de I'equipement qui est a 
I'origine du paquet de resolution d'adresse. Ce numero EUI-64 est utile pour 
identifier de maniere unique I'equipement qui est a I'origine du. paquet de 
resolution d'adresse. 

Un champ denomme "sequence_number" ("numero de 
s6quence") et note 612, represente sur 12 bits, permet d'identifier ce paquet de 
maniere unique dans I'equipement qui est a I'origine du paquet de resolution 
d'adresse. . 

Un champ denomme "management" ("gestion") et note 613, 
represente sur 20 bits, permet d'associer des informations a chaque 
enregistrement de la table selon le type de la table envisagee. 

Dans le cas d'une table de verification dite de "diffusion" (utilisee 
pour gerer la diffusion d'un paquet de resolution d'adresse de telle sorte que ce 
paquet soit transmis sur chaque bus du reseau, une et une seule fois), le 
champ "management" peut par exemple contenir une information indiquant si 
un paquet de resolution d'adresse a deja ete soit recu par I'equipement 
d'interconnexion ou "portal", soit transmis par celui-ci (une valeur booleenne 
peut par exemple etre suffisante). 

Dans le cas d'une table de verification dite de "reponse" (utilisee 
pour g6rer la non-duplication d'une r6ponse vers I'equipement qui est a I'origine 
d'un paquet de resolution d'adresse), le champ "management" peut, par 
exemple, contenir une information indiquant si un paquet reponse a deja 6te 
soit regu par I'equipement d'interconnexion ou "portal", soit transmis par celui-ci 
(une valeur booleenne peut par exemple etre suffisante). 

Selon une premiere variante non decrite ici, un compteur pourrait 
apporter des informations supplementaires sur le fait que plusieurs reponses, 
c'est-a-dire plusieurs descripteurs de chemin, existent et done qu'un choix 
pourrait etre fait sur le descripteur de chemin a retenir selon des criteres 
predefinis comme, par exemple, le plus court chemin. 
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Cette variante impose alors de definir un protocole de 
communication entre les differents equipements d'interconnexion ou "portals" 
afin d'effectuer le changement de descripteur de chemin a utiliser. 

Dans une deuxieme variante non decrite ici, c'est Talpha portal" 
5 qui centralise toutes les r6ponses recues au niveau du bus local ou se situe 
I'equipement qui est a I'origine du paquet de resolution d'adresse, qui decide 
de retenir, selon des criteres predefinis comme, par exemple, le plus court 
chemin, un descripteur de chemin, et qui n'envoie finalement qu'un seul paquet 
reponse vers I'equipement qui est a I'origine du paquet de resolution d'adresse. 
10 Une troisieme variante consiste a utiliser comme Informations 

dans le champ "management", en plus de I'indicateur de passage de paquet de 
resolution d'adresse ou de paquet reponse deja transmis, une valeur indiquant 
par exemple la duree en unites de temps correctement definie ("timeout" en 
terminologie anglo-saxonne) au-dela de laquelle cet enregistrement n'est plus 
1 5 significatif et peut done etre detruit. 

Une quatrieme variante consiste a n'utiliser qu'une seule table de 
verification a la fois pour la "diffusion" et les "reponses". Dans ce cas, le champ 
"management" peut se decomposer entre deux champs, I'un contenant des 
informations relatives a la diffusion de paquet de resolution d'adresse, I'autre 
20 aux paquets reponses a ce paquet de resolution d'adresse. 

La figure 16 est une vue schematique de I'algorithme d'un 
procede de reception d'un paquet de resolution d'adresse au niveau d'un 
Squipement d'interconnexion ou "portal" d'un pont. 

Les instructions ou etapes du procede sont stockees dans la 
25 memoire ROM de chaque pont du reseau. 

Au niveau du bus source, le paquet de resolution d'adresse emis 
par I'equipement source est decrit en reference a la figure 13. 

Ce paquet doit etre compris par les equipements d'interconnexion 
ou "portals" sources qui vont le traduire en un paquet de resolution d'adresse 
30 tel que represents sur la figure 13. 
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Au cours d'une etape 701, un paquet de resolution d'adresse est 
regu au niveau d'un equipement d'interconnexion ou "portal". Au cours de 
I'etape 702, les champs "EUI-64 source" et n sequence_number" decrits 
precedemment en reference a la figure 13 sont lus. 

Au cours de I'etape 703, le precede prevoit de verifier si un 
enregistrement elementaire ayant le numero EUI-64 source qui vient d'etre lu 
dans le paquet recu existe deja dans la table de verification 600, representee a 
la figure 15, a partir des champs EUI-64 source haut et bas presents dans cette 
table. 

Dans le cas ou I'enregistrement n'existe pas, au cours de I'etape 
704, le precede prevoit d'en creer un avec les valeurs des champs "EUI-64 
source" et "sequence_number" lus dans le paquet recu, par exemple 
I'enregistrement 601 represents a la figure 15, puis se poursuit par I'etape 709. 

Dans la cas ou I'enregistrement existe deja dans la table de 
verification, au cours de I'etape 705, le precede prevoit de verifier que le 
numero de sequence lu a partir du paquet recu est strictement superieur au 
numero de sequence courant de I'enregistrement, par exemple note 612 en 
figure 15. 

Dans le cas negatif (plus petit ou egal), lors de I'etape 706, le 
paquet de resolution d'adresse est ignore ; il se peut par exemple que ce soit 
un paquet plus ancien et qui, de toute facon, n'est plus valide. 

Dans le cas positif, le precede precede a une mise a jour du 
numero de sequence de I'enregistrement avec celui lu du paquet recu, au 
cours de I'etape 707, ainsi que des informations de gestion (comme celles 
precedemment mentionnees, telles que, par exemple, une valeur booleenne 
indiquant si un paquet de resolution d'adresse a deja transite sur le bus vu par 
I'equipement d'interconnexion ou "portal", et/ou un compteur indiquant combien 
de paquets identiques de resolution d'adresse ont ete detecte sur le bus vu par 
I'equipement d'interconnexion ou "portal", et/ou une valeur indiquant par 
exemple la duree en unites de temps correctement definie ("timeout" en 
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terminologie anglo-saxonne) au-dela de laqueile cet enregistrement n'est plus 
significatif et peut done etre detruit), au cours de I'etape 708. 

Au cours de I'etape 709, le precede prevoit de verifier si 
I'equipement d'interconnexion ou "portal" a connaissance de I'equipement 
recherche, identifie par les champs "Dev_EUI_64_hi" et "Dev_EUI_64 lo", 
notes respectivement 565 et 566 sur la figure 13. 

Autrement dit, dans le cas oCi I'equipement recherche se situe sur 
le meme bus (ce bus est dit "bus destination") que I'equipement 
d'interconnexion ou "portal" en question, alors ce dernier possede son numeYo 
EUI-64 dans une table interne qui n'est pas decrite dans ce contexte car elle 
est definie dans le cadre des specifications en cours du standard pont 1394. 

Dans le cas positif, au cours de I'etape 710, le precede prevoit 
d'effectuer les operations de creation et/ou de mise a jour dans la table de 
routage precedemment decrite en reference aux figures 8 et 9, puis d'initier 
renvoi d'un paquet reponse 580, tel que decrit en reference a la figure 14, audit 
paquet de resolution d'adresse. 

Les champs de ce paquet reponse 580 sont notamment 
positionnes en utilisant les valeurs des champs du paquet de resolution 
d'adresse de la fagon suivante : 

-le champ descripteur de chemin 561 est utilise pour positionner 
les champs 581, 582, 587 et 588, 

-le champ "response_packet_type_specific_information" 567 est 
utilise pour positionner le champ de m§me nom 589, 

- le champ "sequence_number" 562 est utilise pour positionner le 
champ de meme nom 591 , 

- les champs "Src_EUI_64_hi" et "Src_EUI_64_io" respectivement 
notes 563 et 564 sont utilises pour positionner les champs de memes noms 
592 et 593. 

Dans le cas negatif, au cours de I'etape 71 1, le precede prevoit de 
verifier si I'equipement d'interconnexion ou "portal" a recu le paquet de 
resolution d'adresse du bus sur lequel il est situe (sinon cela signifie que le 
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paquet a ete recu du (ou d'un) "porta!" du pont auquel appartiennent ces 
"portals"). 

Dans le cas positif (paquet recu du bus), le procede mis en oeuvre 
au niveau de I'equipement d'interconnexion ou "portal" prevoit d'envoyer, au 
cours de I'etape 712, le paquet a (aux) I' (les) equipement(s) d'interconnexion 
ou "portal(s)" constituant le pont. 

Dans le cas negatif (paquet recu de I'equipement d'interconnexion 
ou "portal"), le procede mis en ceuvre au niveau de I'equipement 
d'interconnexion ou "portal", au cours de I'etape 713, met a jour le descripteur 
de chemin du paquet de resolution d'adresse et I'envoie sur le bus, propageant 
ainsi la diffusion du paquet a travers le reseau de bus. 

Le descripteur de chemin ayant une taille finie, lorsque ce 
descripteur de chemin du paquet de resolution d'adresse ne peut plus etre mis 
a jour, la transmission ou diffusion dudit paquet de resolution d'adresse est 
stoppee. Ce traitement permet de controler le mecanisme de propagation du 
paquet de resolution d'adresse et, par la meme, permet de detecter et de 
resoudre les problemes de bouclage. 

Suite aux etapes 710, 712 et 713, le traitement du paquet de 
resolution d'adresse se trouve alors termine et le procede revient a son etape 
initiale (701) d'attente d'un nouveau paquet. 

La figure 17 est une vue schematique de I'algorithme d'un 
procede de reception d'un paquet de donnees de reponse, suite a remission 
d'un paquet de resolution d'adresse, au niveau d'un equipement 
d'interconnexion ou "portal" d'un pont situe sur le bus ou se trouve I'equipement 
qui est a I'origine du paquet de resolution d'adresse. 

Les instructions ou etapes d'un tel procede sont stockees dans la 
memoire ROM du pont considere. 

La reception d'un paquet de donnees de reponse peut rev£tir 
deux formes : soit il s'agit d'un paquet de donnees de reponse emis par un 
equipement d'interconnexion ou "portal" distant signifiant la presence de 
I'equipement recherche sur son bus, soit il s'agit d'un paquet de donnees de 
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reponse emis par un equipement d'interconnexion ou "portal" local au bus 
source et, dans ce cas, il s'agit du seul et unique paquet envoye a I'equipement 
qui est a I'origine du paquet de resolution d'adresse. 

Au cours d'une etape 751 , le procede mis en ceuvre au niveau de 
5 requirement d'interconnexion ou "portal" du bus ou se trouve I'equipement qui 
est a I'origine du paquet de resolution d'adresse, prevoit d'attendre un 
evenement associe a un paquet de reponse, c'est-a-dire ou bien la reception 
d'un paquet de reponse ou alors I'ecoulement d'une du^ree d'attente maximum 
predefinie depuis remission du paquet de resolution d'adresse. 
10 Au cours de I'etape suivante 752, le procede prevoit de verifier si 

I'evenement en question est effectivement un paquet de r6ponse au paquet de 
resolution d'adresse. 

Dans le cas positif, au cours de I'etape 753, le procede prevoit de 
verifier si le type du paquet de reponse recu est un paquet emis par un 
15 equipement d'interconnexion ou "portal" local au bus (paquet reponse unique 
envoye a I'equipement qui est a I'origine du paquet de resolution d'adresse). 

Dans le cas negatif, au cours de I'etape 754, le paquet de 
reponse est acquitte comme decrit dans le standard 1394-95 et le paquet de 
reponse etant base sur un paquet primaire asynchrone de type requdte 
20 ("request" en terminologie anglo-saxonne), celui-ci doit etre acquitte par un 
paquet de type reponse ("response" en terminologie anglo-saxonne). 

Dans le cas negatif de la verification faite a I'etape 752, celle-ci 
est suivie par I'etape 760. 

Au cours de I'etape 755, le procede prevoit de verifier si un 
25 paquet de reponse pour le paquet "de resolution d'adresse a deja ete recu par 
I'equipement d'interconnexion ou "portal" ou detecte sur le bus "source" ou si 
un acquittement negatif n'a pas deja ete genere sur le bus source. 

Dans le cas negatif ou, a priori, aucun paquet reponse n'est 
attendu, au cours de I'etape 758, le procede prevoit d'ignorer le paquet et de 
30 revenir a I'etape initiate 751 . 
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Dans le cas positif, ou effectivement tin paquet reponse est 
attendu, au cours de I'etape 756, le proc6de prevoit de memoriser la reception 
ou la detection d'un paquet reponse. 

Puis, au cours de I'etape 757, dans le cas ou le paquet reponse 
5 precedemment recu n'etait pas deja un paquet reponse unique envoye a 
I'equipement qui est a I'origine du paquet de resolution d'adresse, le procede 
prevoit d'envoyer un paquet reponse unique a I'equipement qui est a I'origine 
du paquet de resolution d'adresse. 

Au cours de I'etape 760, le procede prevoit de verifier si la duree 
10 d'attente maximum predefinie s'est ecoulee depuis Remission du paquet de 
resolution d'adresse. La duree d'attente doit etre correctement choisie, par 
exemple de telle sorte qu'elle soit superieure au temps du plus long parcours 
aller d'un paquet de resolution d'adresse additionne au temps de parcours de 
I'eventuel paquet reponse correspondant. Dans le cas negatif, le processus 
15 traite le cas d'erreur au cours de I'operation 761 . Dans le cas positif, I'etape 760 
est suivie d'une etape 762. 

Au cours de I'etape 762, si aucune operation n'a ete detectee sur 
le bus source, le procede prevoit d'envoyer a I'equipement qui est a I'origine du 
paquet de resolution d'adresse un paquet de reponse signalant qu'aucun 
20 equipement repondant au champ "EUI-64 source" precise dans le paquet de 
resolution d'adresse n'a ete trouve, et ce, pendant la duree d'attente maximum 
autorisee. Le procede prevoit ensuite de revenir a I'etape initiate 751. 

La figure 18 est une vue schematique de I'algorithme d'un 
procede de gestion de la longueur des identificateurs de ponts ou labels de 
25 routage au niveau d'un bus en fonction de la capacite du bus. Les etapes ou 
instructions de ce procede sont stockees dans une memoire ROM d'au moins 
un des ponts relies au bus. 

II convient de noter que le pont considere relie deux parties d'un 
reseau entre elles, I'une des parties etant constitute du bus relie audit pont. 
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Au cours d'une etape 901, le precede prevoit de detecter un 
evenement indiquant une premiere initialisation d'un bus auquel le pont est 
connecte. 

Au cours de I'etape 902, on determine pour ledit bus la capacite 
5 en bande passante (plus grande bande passante commune a tous les 
p6ripheriques presents sur ce bus). 

II convient de noter que la capacite en bande passante ou debit 
binaire du bus constitue une caracteristique de celui-ci. ^ 

Ensuite, au cours de I'etape 903, le precede prevoit de verifier, 
10 pour le bus, si la capacite dudit bus en bande passante est inferieure au debit 
binaire reference S400 par la norme 1394-95 (S400 signifiant un debit de 
393,216 Mbit/s). 

Dans le cas negatif, au cours de I'etape 904, il est verifie, pour le 
bus, si cette capacite du bus en bande passante est inferieure au debit 
15 reference S800 par le standard 1394-95 (S800 signifiant un debit de 786,432 
Mbit/s). 

Selon la valeur de la capacite en bande passante dudit bus, le 
precede prevoit de fixer, d'une part, la longueur en bits de I'identificateur ou 
label de routage au niveau dudit bus au cours des etapes 905, 907 et 909, 

20 puis, d'autre part, le nombre maximum de ponts ou d'equipements 
d'interconnexion de ponts ("portals") autorises sur ledit bus ("max_bridge" en 
terminologie anglo-saxonne), ceci au cours des etapes 906, 908 et 910. 

On notera que pour une longueur en bits de I'identificateur ou 
label de routage de n bits, seulement 2 n -1 valeurs d'identificateurs ou labels 

25 de routage" sont autorisees car une valeur particuliere dite de separation 
(marqueurou separateur) est reservee. 

Au cours de I'etape 911, on affecte un identificateur de routage 
constant et unique a I'equipement d'interconnexion ou "portal" du pont 
connecte au bus. Cette valeur d'identificateur de routage est avantageusement 

30 calculee de facon similaire par tous les equipements d'interconnexion ou 
"portals" a partir de la connaissance des identificateurs virtuels associes a 
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chaque equipement d'interconnexion ou "portal" du bus considere. Par 
exemple, la valeur de I'identificateur de routage est definie pour chaque 
equipement d'interconnexion par ordre croissant de la valeur de I'identificateur 
virtuel et, ainsi, Talpha portal" se verra assigner un identificateur de routage de 
valeur '0'. 

Au cours de I'etape 912, le precede prevoit de verifier, pour le 
bus, si la valeur de I'identificateur de routage affecte a I'equipement 
d'interconnexion ou "portal" du pont en question est infeneure au nombre 
maximum de ponts autorises sur ledit bus. Dans le cas negatif, au cours de 
I'etape 914, le pont est positionne dans I'etat "desactive" ("disabled" en 
terminologie anglo-saxonne) et I'algorithme se poursuit par I'etape 915 et une 
valeur particuliere representative de cet "etat" est definie pour I'identificateur de 
routage de I'equipement d'interconnexion ou "portal" considere. 

Par exemple, si le codage des identificateurs a lieu sur 3 bits, on 
ne peut pas identifier plus de sept ponts dans un champ d'informations 
d'identifications. 

Ainsi, si Ton connecte un huitieme pont au bus, celui-ci ne sera 
pas gere au niveau du bus et aucun identificateur de routage valide ne lui sera 
affecte (pont "desactive"). 

Dans le cas positif, au cours de I'etape 913, les differents 
parametres et variables permettant la mise en ceuvre du routage decrit dans le 
present document sont initialises. 

L'etape 915 consiste a attendre un evenement de type 
initialisation de bus ("bus reset" en terminologie anglo-saxonne). 

Dans le cas ou cet evenement se produit, au cours de I'etape 916, 
I'algorithme verifie si la configuration des ponts au niveau du bus a change (par 
exemple un pont a ete nouvellement connecte ou un pont existant a ete 
deconnecte). 

Dans le cas negatif, on revient a I'etape precedente 915. 
Dans le cas positif, au cours de I'etape 917, la mise en ceuvre du 
routage decrit dans le present document est suspendue de telle sorte que plus 
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aucun paquet ne peut entrer sur le bus ou sortir de ce bus par I'intermediaire du 
pont. 

L'etape 918 consiste a attendre pendant une duree suffisante 
predefinie ("time out" en terminologie anglo-saxonne) afin que tout peripherique 
5 utilisant ce pont dans son descripteur de chemin pour communiquer avec un 
peripherique "distant" considere ce descripteur de chemin comme obsolete. En 
consequence, le peripherique doit par exemple generer a nouveau un paquet 
de resolution d'adresse avant de pouvoir reprendre toute, communication. 

L'etape 902 est ensuite executee. 
10 Une autre variante, non decrite ici consiste, par exemple, pendant 

I'intervalle de temps entre la suspension de la mise en oeuvre du routage decrit 
dans le present document (etape 917) et la revalidation de cette mise en ceuvre 
du routage, a acquitter d'une facon particuliere tout paquet desirant transiter via 
le pont. 

15 La figure 19 est une vue schematique de I'algorithme d'un 

procede de gestion de la longueur des identificateurs de ponts ou labels de 
routage au niveau d'un bus en fonction du nombre de ponts et done 
d'equipements d'interconnexion ou "portals" connectes au bus. Les etapes ou 
instructions de ce procede sont stockees dans une memoire ROM d'au moins 

20 un des ponts relics au bus. 

L'algorithme de ce procede ressemble fortement a celui decrit 
prec6demment en reference a la figure 18, la difference portant principalement 
sur la caracteristique du bus utilisee pour decider de la longueur de 
I'identificateur ou label de routage a utiliser. 

25 Dans la figure 18, cette caracteristique est la capacite en bande 

passante ou debit binaire d'un bus donne, I'objectif etant d'eviter d'autoriser un 
trop grand nombre de communications transitant sur ledit bus. A cette fin, un 
pont est mis dans I'etat "desactive" pour qu'il ne puisse plus faire transiter 
d'information. On note que dans le procede de la figure 18, on cherche a 

30 prevenir toute congestion. 
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Dans I'aigorithme de la figure 19, la caracteristique du bus qui est 
prise en compte est le nombre de ponts ou d'equipements d'interconnexion ou 
"portals" connectes sur ledit bus. En fonction du nombre de ponts sur ledit bus 
un certain nombre de bits est necessaire afin de pouvoir tous les identifier de 
5 facon unique. 

Cet algorithme veille egalement a ne pas utiliser de bit inutilement 
pour cette identification. L'algorithme permet aussi de mettre un pont dans l'6tat 
"desactive" dans le cas ou trap de bits sont necessaires pour ridentification 
dudit pont. 

10 D'autres variantes, non decrites dans le present document, 

peuvent aisement etre envisagees a partir d'autres caracteristiques d'une partie 
du reseau, par exemple un bus, qui seront prises en compte dans la decision 
d'affectation de la longueur de I'identificateur ou label de routage a utiliser. 

Au cours d'une etape 951, on detecte un ev§nement indiquant 
15 une premiere initialisation d'un bus auquel le pont est connecte. 

L'etape 952, determine pour ledit bus le nombre de ponts ou 
d'equipements d'interconnexion ou "portals" presents sur ce bus. 

Ensuite, le proc6de prevoit de verifier, pour ce bus, si le nombre 
de ponts est inferieur a 3 au cours de l'etape 953, sinon s'il est inferieur a 7 au 
20 cours de l'etape 954 et sinon s'il est inferieur a 15 au cours de l'etape 955. 
Dans la negative, I'algorithme se poursuit par l'etape 965. 

Selon la valeur du nombre de ponts connectes audit bus, on fixe, 
d'une part, la longueur en bits de I'identificateur ou label de routage au niveau 
dudit bus au cours des etapes 956, 958 et 960, puis d'autre part, le nombre 
25 maximum de ponts ou d'equipements d'interconnexion ou "portals" autorises 
sur ledit bus ("max_bridge" en terminologie anglo-saxonne), ainsi que le 
nombre minimal d'equipements d'interconnexion ou "portals" pour ladite 
longueur en bits de I'identificateur ou label de routage ("min_bridge" en 
terminologie anglo-saxonne), ceci au cours des etapes 957, 959 et 961 . 
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Au cours de I'etape 911, on affecte un identificateur de routage 
constant et unique a I'equipement d'interconnexion ou "portal" du pont 
connects au bus. 

Cette valeur d'identificateur de routage est avantageusement 
calculee de facon similaire par tous les equipements d'interconnexion ou 
"portals", a partir de la connaissance des identificateurs virtuels associes a 
chaque equipement d'interconnexion ou "portal" du bus considere. 

Par exemple, la valeur de I'identificateur >de routage est d<§finie 
pour chaque equipement d'interconnexion par ordre croissant de la valeur de 
I'identificateur virtuel et, ainsi, Talpha portal" se verra assigner un identiflcateur 
de routage de valeur '0'. 

Au cours de I'etape 963, le precede prevoit de verifier, pour ledit 
bus, si la valeur de I'identificateur de routage affecte a I'equipement 
d'interconnexion ou "portal" du pont en question est inferieure au nombre 
maximum de ponts autorises sur ledit bus. 

Dans le cas negatif, au cours de I'etape 965, le pont est 
positionne dans I'etat desactive ("disabled" en terminologie anglo-saxonne) et 
une valeur particuliere representative de cet "etat" est definie pour 
I'identificateur de routage de I'equipement d'interconnexion ou "portal" * 
considere, puis I'algorithme se poursuit par I'etape 966. 

Dans le cas positif, au cours de I'etape 964, les differents 
parametres et variables permettant la mise en oeuvre du routage decrit dans le 
present document sont initialises. 

L'etape 966 consiste a attendre un evenement de type 
initialisation de bus ("bus reset" en terminologie anglo-saxonne). Dans le cas 
ou cet evenement se produit, au cours de I'etape 967, I'algorithme verifie si la 
configuration des ponts au niveau du bus a change (par exemple un pont a ete 
nouvellement connecte ou un pont existant a ete deconnecte) et si le nombre 
de ponts ou equipements d'interconnexion ("portals") est en dehors de 
I'intervalle defini precedemment par min_bridge et max_bridge. 

Dans le cas negatif, I'algorithme revient a I'etape precedente 966. 
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Dans le cas positif, au cours de l'etape 968, la mise en oeuvre du 
routage decrit dans le present document est suspendue de telle sorte que plus 
aucun paquet ne peut entrer sur le bus ou sortir de ce bus par Pintermediaire 
dudit pont. 

L'etape 969 consiste a attendre pendant une duree suffisante 
predefinie ("time out" en terminologie anglo-saxonne) afin que tout peripherique 
utilisant ce pont dans son descripteur de chemin pour communiquer avec un 
peripherique "distant" considere ce descripteur de chemjn comme obsolete. En 
consequence, le peripherique doit par exemple regenerer un paquet de 
resolution d'adresse avant de pouvoir reprendre toute communication. 

L'etape 952 est ensuite executee. 

II convient de remarquer que lorsqu'un pont relie entre elles deux 
parties d'un reseau, deux longueurs d'identificateurs differentes peuvent etre 
determinees respectivement pour les deux equipements d'interconnexion ou 
"portals" du pont considere en fonction de deux caracteristiques respectivement 
propres a chacune desdites deux parties du reseau. 

Ainsi, dans un tel cas de figure, le marqueur qui delimite deux 
champs d'informations d'identification, respectivement du chemin a parcourir et 
parcouru par le paquet de donnees, voit sa taille ou longueur varier en 
consequence, afin que la difference de taille ou longueur entre les deux 
identificateurs des deux equipements d'interconnexion ou "portals" n'ait pas 
d'incidence sur la longueur totale du champ constitue du marqueur et des deux 
champs d'informations d'identification qui doit etre fixe. 

La figure 20 est une vue schematique d'un reseau de 
communication note 1500 selon I'invention, de type conforme a la norme IEEE 
1394 et qui comporte plusieurs bus de communication serie conformes a la 
norme IEEE 1394 et dont seul certains sont references sur cette figure. 

Les bus de communication serie notes 1502 a 1518 sont 
interconnects deux a deux par des ponts dont seuls certains sont references 
sur la figure 20 et sont notes 1520 a 1532. 
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II convient de noter que chaque pont de la figure 20 a par 
exemple I'allure du pont note entre parentheses 1520 et represents a la figure 
3. 

Chaque pont comporte deux equipements d'interconnexion ou 
"portals" qui permettent respectivement de connecter les bus entre eux. 

Sur la figure 3, les elements du pont qui sont references 12, 14, 
16, 18, 20, 22, 24, 26, 28, 34, 36, 38, 40, 42 et 44 sont communs a chacun des 
equipements d'interconnexion ou "portals" de ce pont et seuls les blocs de 
composants PHYLINK 1394 notes 30 et 32 sur cette figure sont specifiques 
respectivement a chaque equipement d'interconnexion. 

Ainsi, chaque equipement d'interconnexion d'un pont de la figure 
20 comporte un bloc de composants PHYLINK 1394 identique au bloc 30 ou 32 
de la figure 3, ainsi que les autres elements enonces ci-dessus et qui sont 
communs a chacun desdits equipements d'interconnexion. 

Toutefois, dans certains cas, les equipements d'interconnexion ou 
"portals" d'un pont sont physiquement eloignes les uns des autres (cas d'une 
liaison radio) et chacun desdits equipements d'interconnexion comporte alors 
ses propres elements identiques a ceux enonces ci-dessus et notes 12 a 44. 

De maniere identique a ce qui est represente a la figure 3, les 
ponts notes 1520 a 1532 peuvent etre integres dans un appareil de traitement 
de donnees (par exemple un ordinateur) ou bien constituer eux-m§mes ledit 
appareil. 

Sur la figure 3, le pont 1520 est integre dans un ordinateur 1527. 

Les ponts represents a la figure 20 interconnectent chacun au 
moins deux parties du reseau 1500, lesdites parties etant, dans I'exemple 
represente sur cette figure, les bus de communication serie conformes a la 
norme IEEE 1394. 

Par ailleurs, des equipements de type peripherique dits applicatifs 
sont egalement relies aux bus de communication. 

Deux de ces equipements particuliers, notes 1540 et 1542 sont 
respectivement relies aux bus 1502 et 1518 de la figure 20. 
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Ces peYipheriques constituent respectivement ce que Ton appelle 
un peripherique source, note 1540, et un peripherique destinataire, note 1542. 

Ces deux peripheriques sont relies a des bus eloignes I'un de 
I'autre et qui sont separes par plusieurs ponts. 

Les ponts notes 1520 et 1521 sur la figure 20 constituent des 
ponts dits d'extremites et ceux-ci sont separes I'un de I'autre par plusieurs 
ponts appeles pont intermediates et notes 1522, 1524, 1526, 1528, 1530 et 
1532. 

Le pont d'extremite 1 520 est un pont a partir duquel un paquet de 
donnees asynchrone est 6mis sur le reseau. 

Dans le cas reprSsente a la figure 20, le pont note 1520 est qualifie 
de pont "source" et le pont note 1521 est qualifie de pont "destinataire". 

II convient de noter que, dans ce qui suit, les descriptions 
precedentes, faites en reference aux figures 1 a 19 restent valables. 

Lorsqu'un paquet de donnees par exemple de type asynchrone 
est emis par le pont source note 1520 sur la figure 20, en direction du pont 
destination note 1521 surcette meme figure, il faut que ce paquet contienne les 
informations d'identification du chemin a parcourir dans le reseau. 

Ces informations d'identification du chemin comprennent 
differents identificateurs dits de routage permettant d'identifier les ponts et plus 
particulierement les equipements d'interconnexion ou "portals" rencontres par 
ledit paquet sur son chemin. 

Par exemple, un identificateur de routage est code sur 3 bits. 

Ainsi, comme represents a la figure 20, les informations 
d'identification du chemin a parcourir par le paquet de donnees 6mis par le pont 
1520 comprennent sept identificateurs de routage correspondant 
respectivement aux differents equipements d'interconnexion ou "portals" des 
ponts notes 1522, 1524, 1526, 1528, 1530, 1532 et 1521. 

De ce fait, vingt et un bits seront necessaires pour coder les 
informations d'identification du chemin du paquet de donnees. 
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I! convient de noter qu'il faut normalement enlever a ces vingt et 
un bits trois bits n6cessaires pour le codage du champ d'informations appele 
separateur ou marqueur et qui a pour fonction de delimiter les premier et 
deuxieme champ d'informations correspondant respectivement au chemin a 
parcourir et au chemin parcouru par le paquet de donnees. 

Par consequent, le descripteur de chemin utilise lors de la 
description faite en reference aux figures 1 a 11, etant code sur vingt bits, 
possede une taille limitee qui ne lui permet pas d'effectuer le routage du paquet 
asynchrone considere dans le cas represents a la figure 20. 

Un tel paquet de donnees asynchrone est repr6sente par la 
reference 1550 sur la figure 21 . 

Ce paquet possede la structure representee a la figure 2. 

II comporte une premiere zone notee 1552 comportant differents 
types d'informations, parmi lesquelles des informations dites d'identification du 
chemin du paquet de donnees dans le reseau. Ces informations sont 
contenues dans un ensemble de champs note 1554 sur la figure 21 et qui 
reprend I'ensemble des champs 80 et 81 de la figure 2. 

Plus particulierement, I'ensemble des champs 1554 comporte cinq 
champs notes 1554a, 1554b, 1554c, 1554d et 1554e qui sont respectivement 
identiques aux champs 232, 233, 234, 235 et 236 du paquet 231 de la figure 7. 

Le paquet 1550 comporte egalement une deuxieme zone qui 
comprend un bloc de donnees note "datal" reference 1556 et qui est identique 
au bloc de donnees note 89 sur la figure 2. 

Ce paquet comporte egalement un champ denomme 
"header1_CRC note 1558 et qui est identique au champ note 88 sur la figure 
2. 

Le paquet comporte egalement un champ denomme "data1-CRC" 
note 1560 et qui est identique au champ note 90 sur la figure 2. 

La premiere zone 1552 du paquet comporte les champs notes 82, 
83, 84, 85, 86 et 87 representes a la figure 2. 
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La figure 22 represente un algorithme sur lequel est base le 
precede de transfert d'un paquet de donnees selon I'invention et qui est mis en 
ceuvre au niveau d'un pont intermediate 1522 de la figure 20. 

II convient de noter que tous les ponts represents dans le reseau 
de communication 1500 de la. figure 20 sont capables de mettre en ceuvre un 
tel procede. 

Les differentes instructions ou etapes de ce procede font partie 
d'un programme informatique stocke dans la memoire ROM du pont considere, 
memoire qui est analogue a la memoire ROM 14 du pont de la figure 3. 

Dans la representation qui est faite a la figure 21, la premiere 
zone 1552 constitue un en-tete du paquet 1550. 

Toutefois, il serait envisageable de placer cette premiere zone a la 
fin du paquet, apres le champ 1560. 

Le procede de traitement selon I'invention mis en ceuvre au 
niveau du pont source 1520 et base sur I'algorithme represente a la figure 24 
prevoit d'ajouter au paquet 1550 au moins une troisieme zone notee 1562 et 
qui constitue egalement dans la representation faite a la figure 21 un autre en- 
tete de paquet. 

Toutefois, il convient de noter que cette troisieme zone pourrait 
egalement etre placee en fin de paquet. 

Cette troisieme zone est egalement destinee a recevoir des 
informations d'identification du chemin du paquet dans le reseau. 

La troisieme zone 1562 est separee de la premiere zone 1552 du 
paquet 1550 par un champ denomme "header2_CRC" note 1564 et qui est 
similaire au champ 1558. 

Un autre champ note 1566 et denomme "data2_CRC" est place 
en fin de paquet apres la deuxieme zone 1556 renfermant les donn6es utiles. 

La troisieme zone 1562 comporte egalement un ensemble de 
champs d'informations note 1568 destine a recevoir des informations 
d'identification du chemin du paquet dans le reseau et qui est analogue a 
I'ensemble de champs note 1554 du paquet 1550. 
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II convient de noter que les premiere et troisieme zones 
possedent chacune une structure identique qui est conforme aux en-tetes des 
paquets vehicules. 

Notamment, la structure est conforme aux en-tetes des paquets 
vehicules dans les reseaux de communication conformes a la norme 
IEEE1394. 

II convient de noter que dans certaines applications il peut etre 
utile que les premiere et troisieme zones ne possedent pas une structure 
conforme au meme protocole de communication. 

Dans le cas present, le protocole de communication est le m§me 
pour des raisons de simplicity de mise en ceuvre. 

Ainsi, comme represents a la figure 21, le precede selon 
I'invention permet "d'encapsuler" le paquet de donnees 1550 dans un autre 
paquet note 1570 et possedant comme en-tete la troisieme zone 1562, les 
donnees du dit paquet 1570 etant constitutes par les premiere et deuxieme 
zones respectivement notees 1552 et 1556 du paquet 1550. 

^encapsulation du paquet 1550 dans le paquet 1570 du meme 
type, permet d'obtenir une zone d'en-tete supplemental. 

Ainsi, avec I'adjonction de la troisieme zone 1562, le paquet de 
donnees ainsi transforme comporte les deux ensembles de champ 1554 et 
1568 reserves aux informations d'identification du chemin du paquet permettant 
ainsi de transporter un descripteur de chemin contenu non plus sur vingt bits 
mais sur quarante bits. 

Ceci permet bien entendu de faire parcourir a un paquet de 
donnees une plus grande distance entre le pont source et le pont destination 
dans un reseau de communication seloh ('invention. 

Le traitement d'un tel paquet de donn6es 1550 est effectue au 
niveau du pont source 1520 de la figure 20. 

Au cours de ce traitement, le champ 1554c denomme "Des_VID" 
est analogue au champ note 80b sur la figure 2 ainsi qu'au champ note 203 
dans la paquet de donnees 199 de la figure 5 reste inchange. 
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Le champ 1554d denomme "Src_PID" est analogue au champ 
note 81b sur la figure 2 et au champ 235 du paquet 231 sur la figure 7. 

Au cours du traitement selon I'invention, ce champ est remplace 
comme represents sur la figure 7 par un champ 1554f denomme "Src_VID" et 
note 249 dans le paquet 240 de la figure 7. 

Le contenu de ce champ correspond a I'identificateur virtuel du 
' pont considere. 

L'information 1554a notee "index_S" identique au champ 232 
nomme "offset" dans le paquet 231 de la figure 7 est utilisee comme decrit en 
reference a cette figure pour retrouver, dans une table de routage telle que 
celle representee a la figure 8, le descripteur de chemin approprie qui comporte 
les differentes informations d'identification du chemin a parcourir dans le 
reseau pour que le paquet de donnees parvienne au pont destination 1521 . 

II convient de noter que le reste de I'en-tete du paquet de 
donnees 1550 reste inchange. 

Conformement au procede selon I'invention, les informations 
d'identification du chemin constituant le descripteur de chemin sont reparties 
dans les premiere et troisieme zones du paquet 1570. 

Plus particulierement, ces informations sont reparties dans les 
champs denommes "destination_Bus_ID" et "source_Bus_ID" des deux en- 
tetes et qui sont analogues aux champs notes 80a et 81a du paquet de la 
figure 2. 

Comme represents sur la figure 21, 1'ensemble des champs notes 
1568 de la troisieme zone 1562 comporte deux champs notes 1590 et 1592 qui 
sont chacun similaires au champ denomme "Des_VID" du paquet 1550 ainsi 
qu'au champ note 203 du paquet 199 sur la figure 5 et sont tous les deux 
positionnes a une valeur non significative, notee 3f 16 , indiquant ainsi que I'en- 
tete du paquet 1570 encapsule un autre paquet de donnees. 

Les autres champs contenus dans la troisieme zone ou en-tete 
1562 du paquet 1570 reprennent toutes les valeurs de I'en-tete 1552 du paquet 
1550, a I'exception toutefois des champs concernant la longueur du paquet 
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denomme "data-length" d'un paquet de donnees de type "data block", 
renfermant un bloc de donnees du champ "tcode" analogue au champ 84 de la 
figure 2. 

Ce dernier champ denomme "tcode" definit le type du paquet, a 
5 savoir s'il s'agit d'un paquet contenant quatre octets de donnees ("data quadlet 
packet" en terminologie anglosaxonne) ou plusieurs blocs de donnees. 

Dans le paquet 1570 ainsi obtenu , le paquet d'origine note 1550 
constitue la zone de donnees utiles du paquet 1570. 

L'encapsulation de paquets de donnees presente I'avantage, pour 
10 une taille de marqueur ou separateur donnee, d'augmenter le ratio du nombre 
de bits d'informations de routage sur le nombre de bits total utilise pour 
transporter les informations d'identification du chemin. 

II convient de noter que le champ 1558 denomme 
"header1_CRC", de meme que le champ 1560 denomme "data1_CRC" n'ont 
15 pas besoin d'etre transferes d'un pont a I'autre car ils represented une 
information qui est significative au niveau des blocs de composants PHYLINK 
notes 30 et 32 sur la figure 3, lors d'une communication entre un pSripherique 
source et un peripherique destination. 

II convient de noter que le type du paquet defini par le champ 
20 "tcode" peut etre modifie lors d'une encapsulation de paquet, par exemple par 
transformation d'un paquet "data quadlet packet" contenant quatre octets de 
donnees en un paquet contenant plusieurs blocs de donn§es et d<§nomm6 
"data block packet". 

On remarquera toutefois qu'il peut etre utile, selon le nombre 
25 d'informations d'identification de chemin a placer dans le paquet, d'ajouter plus 
d'une troisieme zone analogue a celle notee 1562 sur la figure 21 . 

Lorsque I'operation decapsulation est effectuee au niveau du 
pont source, le paquet obtenu, par exemple note 1570, est route sur le reseau 
de communication 1500, conformement a la description faite en reference aux 
30 figures 1 a 1 1 . 
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La figure 22 represente un algorithme * sur lequel est base le 
precede de transfer! selon I'invention et qui est mis en oeuvre au niveau de 
chaque pont intermediaire du reseau selon I'invention. 

Les differentes instructions ou etapes de ce precede font parties 
d'un programme informatique stocke dans la memoire ROM de chaque pont qui 
est analogue a la memoire ROM 14 du pont 1520 represente a la figure 3. 

La figure 22 represente plus particulierement I'algorithme general 
utilise au niveau des ponts, d'une part, pour recuperer les informations 
d'identification de chemin (descripteur de chemin) d'un paquet mettant en 
oeuvre le mecanisme d'encapsulation qui vient d'etre decrit et pour le 
sauvegarder dans un registre de travail et, d'autre part, apres traitement par 
chaque pont, pour reecrire, dans le paquet destine a quitter le pont, les 
informations d'identification de chemin traitees et contenues dans le registre de 
travail, en tenant compte de I'encapsulation. 

Comme represente a la figure 22, le precede comporte une etape 
1650 au cours de laquelle on precede a un test afin de determiner si le paquet 
recu par le pont intermediaire 1522 est de type asynchrone. 

Dans la negative, le precede pr6voit de se placer en attente de 
reception d'un autre paquet et traite malgre tout le paquet recu de maniere 
appropriee. 

Dans I'affirmative, l'etape 1650 est suivie d'une etape 1651 au 
cours de laquelle le paquet qui vient d'etre recu est considere comme le paquet 
courant pour le pont considere. L'etape 1651 est ensuite suivie d'une etape 
1652 au cours de laquelle il est precede a la lecture, dans I'en-tete 1562 
(troisieme zone)du paquet recu 1570, des champs 1590 et 1592. 

L'etape 1652 est suivie d'une etape 1654 au cours de laquelle on 
precede a la lecture de deux champs notes 1594 et 1596 de I'ensemble de 
champs 1568 de la troisieme zone 1562 du paquet 1570. 

Ces deux champs 1594 et 1596 contiennent une partie des 
informations d'identification du chemin a parcourir par le paquet dans le reseau 
et elles sont respectivement denommees "forward_path0" et "forward_path1". 
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La lecture du champ 1 594 est effectuee de la droite vers la gauche 
alors que la lecture du champ 1596 est effectue de la gauche vers la droite 
(figure 21), ce dernier etant en fait inverse a la lecture. 

Conformement a I'etape 1654, on precede a I'ecriture des 
informations d'identification du chemin a parcourir qui vient d'etre lu dans un 
registre de travail note 1 598 et represents a la figure 23. 

Dans ce registre, par souci de clarte, on a uniquement represente 
les informations d'identification du chemin a parcourir et non celles du chemin 
parcouru. 

II convient de noter que ce registre est inclus dans la memoire RAM 
du pont considere, memoire qui est analogue a celle du pont 1520 represente a 
la figure 3. 

Le registre de travail 1598 comporte par exempie deux parties, Tune 
destinee a contenir des informations d'identification du chemin a parcoun'r et 
I'autre destinee a contenir des informations d'identification du chemin parcouru 
par le paquet. 

Apres ecriture des champs 1594 et 1596 dans le registre de travail 
1598, I'etape 1654 est suivie d'une etape 1656 au cours de laquelle on procede 
a un test afin de determiner si les champs notes 1590 et 1592 de la troisieme 
partie 1562 du paquet courant 1570 (figure 21) sont significatifs. 

Dans I'exemple represente a la figure 21, ces champs ne sont pas 
significatifs et I'etape 1656 est suivie d'une etape 1658 au cours de laquelle le 
paquet "encapsule" qui comporte les premiere et deuxieme zones notees 1552 
et 1 556 devient le paquet courant. 

Cette etape est alors suivie de I'etape 1652 deja decrite ci-dessus et 
qui concerne, dans le cas present, I'operation de lecture des champs notes 
1554c et 1554f de la premiere zone 1552 du paquet "encapsule". 

L'etape suivante 1654 est a nouveau effectuee et on procede alors a 
une lecture des champs notes 1554g, 1554h, 1554i et 1554j, les champs 
1554h, 1554i et 1554j etant inverses a la lecture. 
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Ces champs designent respectivement, les informations 
d'identification du chemin a parcourir par le paquet, denommees 

"forward_path2" et " _path3", un marqueur note "111" et des informations 

d'identification du chemin retour note "back ". 

Au cours de cette meme etape, ces differentes informations 
presentes dans ces champs sont ecrites dans le registre de travail 1598 de la 
figure 23. 

II convient de noter que, dans ce registre, les deux zones delimitees 
par les traits verticaux et les fleches horizontales contiennent des champs 
inverses a la lecture. 

L'etape suivante 1656 permet de verifier, dans le cas present, que 
les informations contenues dans les champs notes 1554c, denommee 
"Des_VID", et 1554f, denommee "Src_VID" sont significatives. 

Ainsi, l'etape 1656 est suivie d'une etape 1660 qui correspond a un 
traitement approprie des informations d'identification du chemin a I'interieur du 
registre de travail 1 598. 

Le traitement effectue dans cette etape reprend les operations de 
gestion effectuees sur les descripteurs de chemin telles qu'enoncees dans la 
description faite en reference aux figures 5 a 7 et aux algorithmes 
correspondants. 

De facon simplifiee, une information d'identification du chemin a 
parcourir contenue dans le champ note 1594 est supprimee de celui-ci par 
suite du passage du paquet de donnees dans le pont 1522, cette information 
d'identification de chemin correspondant a I'identificateur de routage de 
I'equipement d'interconnexion ou "portal" du pont considere par lequel le 
paquet arrive. 

Apres cette suppression d'information, il est prevu de decaler toutes 
les informations contenues dans le registre 1598 represente par I'etat (a) pour 
parvenir au registre 1598 represente par I'etat (b) sur la figure 23. 

Dans I'etat (b) du registre 1598, les informations d'identification de 
chemin denommees "forward_pathO", "forward_path1", "forward_path2" et 
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" path3" sont toutes decades vers la droite du registre, !e decalage 

correspondant a trois bits. 

Trois bits correspondent a la taille d'un identificateur de routage d'un 
equipement d'interconnexion 
5 On constate que la taille des informations d'identification 

representees par "forward_pathO" a ete reduite. 

Des lors que ce traitement Vient d'etre effectue, I'etape 1660 est 
suivie d'une etape 1662 au cours de laquelle le paquet qui a ete recu par le 
pont 1562 est considere comme le paquet courant. 

10 L'unite de calcul CPU du ppnt 1522 execute ensuite I'etape suivante 

1664, au cours de laquelle une lecture du registre de travail 1598 dans l'6tat 
represents par (b) est effectuee, et Ton procede a I'ecriture dans le paquet de 
donnees qui va etre emis sur le reseau, des informations d'identification de 
chemin qui viennent d'etre traitees. 

15 Ces informations denommees "forward_path0", 

"forward_path1" sont d'abord ecrites dans la troisieme zone 1562 du 

paquet de donnees considere et I'etape 1664 est suivie d'une etape 1666 au 
cours de laquelle on determine si les champs notes 1590 et 1592 de la 
troisieme zone du paquet consider^ sont significatifs. 

20 Si ces champs ne sont pas consideres comme significatifs, cela veut 

dire que la zone consideree dans laquelle sont ecrites les informations 
constitue un en-tete supplementaire du paquet (etape de detection d'une 
troisieme zone) et, par consequent, on va prendre en compte comme paquet 
courant le paquet encapsule comportant les premiere et deuxieme zones 

25 notees respectivement 1552 et 1 556, au cours de I'etape suivante 1 668. 

Cela revient a dire que I'on analyse une partie des informations 
d'identification de chemin afin de determiner si le paquet considere comporte 
un en-tete supplementaire. 

L'etape 1668 laisse ensuite la place aux etapes deja enoncees ci- 

30 dessus 1664 et 1666 au cours desquelles on procede a la lecture du registre 
de travail 1598 dans son etat (b), on ecrit les informations d'identification de 
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chemin restant dans ce registre dans la premiere zone 1552 du paquet 
encapsule et on precede a un test sur les champs 1554c et 1554f afin de 
determiner s'ils sont significatifs. 

Dans le cas qui nous interesse, ces champs sont significatifs et 
I'etape 1666 est alors suivie d'une etape 1670 au cours de laquelle on precede 
a remission du paquet de donnees comportant son en-tete supplemental 
1562 sur le reseau. 

La figure 24 represente un algorithme sur lequel est base le precede 
de traitement d'un paquet de donnees selon I'invention et qui est mis en oeuvre 
au niveau du pont source 1520 represente sur la figure 20. - 

Les differentes instructions ou etapes de ce precede font partie d'un 
programme informatique stocke dans la memoire ROM 14 du pont 1520 
represente a la figure 3. 

Suivant une premiere etape 1700 de ce precede, il est verifte si un 
paquet de type asynchrone est a emettre sur le reseau. 

Dans la negative, le precede se place en attente de reception d'un 

tel paquet. 

Dans raffirmative, I'etape 1700 est suivie d'une etape 1702 au cours 
de laquelle ('information denommee "index_S" et notee 1554a du paquet de 
donnees 1550 represente a la figure 20 est utilisee au niveau du pont source, 
dans la table de routage representee a la figure 8, afin d'y recuperer, dans un 
enregistrement elementaire, les informations d'identification du chemin a 
parcourir par le paquet (descripteur de chemin). 

Cette etape de recuperation d'un descripteur de chemin a partir d'un 
index est largement decrite dans la description precedente, faite notamment en 
reference aux figures 8 a 1 1 . 

Au cours de cette meme etape 1702, les informations d'identification 
du chemin a parcourir par le paquet de donnees sont ecrites dans un registre 
de travail qui peut etre identique a celui repr6sente a la figure 23 sous la 
reference 1598. 
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L'etape 1702 est ensuite suivie d'une etape 1704 au cours de 
laquelle on considere que le paquet de donnees 1550 est le paquet courant 
traite au niveau du pont source. 

L'etape suivante, notee 1706, prevoit une operation de lecture du 
5 registre de travail, effectuee en commencant par les informations 
d'identification du chemin parcouru et une operation d'ecriture, dans Pensemble 
des champs note 1554 de la premiere zone 1552 du paquet de donnees 1550, 
des informations d'identification du chemin a parcourir *et du chemin parcouru 
par le paquet de donnees. 
10 Ces informations correspondent a celles que Ton trouve dans les 

champs notes 80a et 81a du paquet represente a la figure 2 et qui sont 
denomm6s "destination_Bus_ID" et "source_Bus_ID". 

L'etape 1706 est suivie d'une etape 1708 au cours de laquelle on 
pratique un test afin de determiner si le registre de travail est vide. 
15 Lorsque le registre de travail n'est pas vide, I'unite de calcul CPU 12 

du pont de la figure 3 execute une etape suivante notee 1710 correspondant a 
un traitement par encapsulation. 

Au cours de cette etape, on procede a un ajout au paquet de 
donnees 1550 d'une troisieme zone 1562 correspondant a un en-tete 
20 supplementaire pour ledit paquet de donnees et qui est initialisee avec des 
valeurs de I'en-tete 1552 (premiere zone) du paquet courant. 

Comme represente sur la figure 21, les champs 1590 et 1592 de cet 
en-tete supplementaire 1562 sont mis a des valeurs non significatives par 
exemple "3f 16 ". 

25 Au cas ou cela s'avere necessaire, l'etape 1710 prevoit egalement 

de mettre a jour le champ correspondant au type de paquet note 84 et 
denomme "tcode" dans le paquet de la figure 2. 

Par exemple, un paquet de type "data quadlet" qui contient par 
definition quatre octets de donnees devient un paquet de type "data block 

30 packet" c'est a dire comprenant plusieurs blocs de donnees. 
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Au cours de cette meme etape, il est egalement prevu de mettre a 
jour le champ correspondant a la longueur du paquet ("data length" en 
terminologie anglo-saxonne). 

Au cours de I'etape suivante notee 1712, il est prevu que le paquet 
courant devienne le paquet encapsule. 

L'etape 1712 est ensuite suivie des etapes 1706 et 1708 au cours 
desquelles on precede a la lecture du registre de travail contenant les 
informations d'identification de chemin du paquet dans^ le reseau (descripteur 
de chemin) et d'ecriture de ces informations dans la premiere zone notee 1552 
du paquet encapsule et, si cette zone est deja remplie, dans la troisieme zone 
1562 du paquet 1570 represente a la figure 21. 

Si le registre de travail n'est pas vide, on precede a une nouvelle 
operation decapsulation en ajoutant une zone supplemental constituant un 
nouvel en-tete et, si le registre de travail est vide, alors I'etape 1708 est suivie 
d'une etape 1714 au cours de laquelle le paquet de donnees 1570 est 6mis sur 
le reseau par le pont source 1520. 

La figure 25 represente un registre de travail note 1730 considere 
dans deux etats represents par (a) et (b). 

Ce registre de travail est inclus dans la memoire RAM du dernier 
pont intermediaire note 1532. 

Le registre ne contient que des informations representatives du 
chemin parcouru par le paquet de donnees dans le reseau. 

II convient de noter qu'au niveau de ce pont intermediaire, il existe 
un autre registre de travail non represente, analogue a celui de la figure 23 et 
qui contient les informations d'identification du chemin a parcourir par le paquet 
de donnees jusqli'a sa destination. 

Avant I'ecriture des informations d'identification de chemin du paquet 
dans ledit paquet de donnees, il est prevu d'effectuer une operation "et" logique 
entre les deux registres de travail contenant chacun respectivement les 
informations d'identification du chemin a parcourir et du chemin parcouru. 
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Comme represents sur la figure 25, I'etat (a) du registre 1730 est 
representatif de ce registre lorsque le paquet de donnees est recu au niveau du 
pont intermediaire 1532. 

L'etat (b) du registre 1730 represente les informations d'identification 
5 du chemin parcouru par le paquet apres traitement selon le mecanisme de 
routage deja decrit en reference a la figure 23. 

On constate en effet qu'une information d'identification de routage 
correspondant a un identificateur de routage de l'6quipement d'interconnexion 
par lequel le paquet est arrive sur le pont intermediaire 1532 a ete" ajoute dans 
10 le champ denomme "backward_pathO". 

Tous les champs d'informations contenus dans le registre 1730 du 
pont ont alors ete dScales de trois bits vers la droite. 

Ces trois bits correspondent au nombre de bits n£cessaires pour 
coder un identificateur de routage d'un equipement d'interconnexion d'un pont. 
15 Comme represente a la figure 26, le paquet de donnees note 1570 

qui encapsule, au moyen de la troisieme zone 1562, le paquet de donnees 
constitue de la premiere zone 1552 et de la deuxieme zone 1556 comporte 
dans les champs d'informations destines a recevoir les informations 
d'identification de chemin du paquet dans le rSseau des informations contenues 
20 dans le registre de travail 1730 (etat (b)), ainsi que celles contenues dans un 
autre registre de travail (non represente) contenant les informations 
d'identification du chemin a parcourir. 

Les informations d'identification du paquet dans le reseau (chemin a 
parcourir et chemin parcouru) sont contenues respectivement dans les 
25 troisieme et premiere zones du paquet 1570, plus particulierement dans deux 
ensembles de champs respectivement notes 1732 et 1734 sur la figure 26. 

La figure 27 represente un algorithme sur lequel est base le procSde 
de traitement d'un paquet de donnees selon I'invention et qui est mis en ceuvre 
au niveau d'un pont destination note 1521 sur la figure 20. 
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Les differentes instructions ou etapes de ce proced§ font partie d'un 
programme informatique stocke dans la memoire ROM du pont considere, 
memoire analogue a la memoire ROM 14 du pont 1520 de la figure 3. 

Lors de la mise en oeuvre du procede de traitement d'un paquet de 
donnees selon I'invention, I'unite de calcul CPU du pont destination execute les 
differentes etapes ou instructions representees sur la figure 27et notamment la 
premiere etape notee 1750. 

Au cours de cette etape, il est proc6de a un test afin de determiner si 
un paquet de type asynchrone est recu. 

Dans la negative, le procede prevoit de se placer en attente de 
reception d'un paquet asynchrone. 

Dans raffirmative, I'etape 1750 est suivie d'une etape 1752 au cours 
de laquelle on considere que le paquet asynchrone recu est le paquet courant 
qui va etre traite par le pont destination. 

Ce paquet est par exemple celui represents sur la figure 26 et 
portant le reference 1570. 

L'etape 1752 de I'algorithme de la figure 27 est suivie de I'etape 
1754 au cours de laquelle on procede a une lecture dans I'en-tete (troisieme 
zone) 1562 du paquet 1570 des champs notes 1590 et 1592 et denommes 
respectivement "destinationJModeJD" et "source_Node_ID". 

II convient par ailleurs de noter que les elements du paquet 1570 
represents sur la figure 26 qui sont identiques a ceux represented sur la figure 
21 portent les mSmes references et ne seront pas rappeles ici. 

L'etape 1754 est suivie d'une etape 1756 au cours de laquelle on 
procede a une lecture dans I'en-tete du paquet courant du champ denomme 
"destination_Bus_ID" et du champ "source_Bus_ID" inverse qui sont 
represents par les champs notes 1736, 1738,1740 et 1742 sur la figure 26. 

En outre, on procede egalement a I'ecriture dans un registre de 
travail identique au registre 1730 de la figure 25 des informations 
d'identification de chemin contenues dans ces champs. 
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L'etape 1756 est suivie d'une etape 1758 au cours de laquelle il est 
examine si les champs 1590 et 1592 sont non significatifs. 

Dans le cas represents a la figure 26 oti un paquet a ete encapsule 
a I'interieur d'un autre paquet, les champs precites sont effectivement non 
significatifs et l'etape 1758 est suivie d'une etape 1760 correspondant a un 
traitement de "desencapsulation". 

Au cours de cette etape, il est precede, si cela s'avere necessaire, a 
la memorisation de la valeur du champ correspondant a la longueur du paquet 
("data length" en terminologie anglosaxonne). 

On precede egalement a la suppression de I'en-tete supplemental 
(troisieme zone) 1562 et Ton obtient, le paquet de donn6es comportant la 
premiere zone 1552 et la deuxieme zone 1556, a I'exception de la troisieme 
zone 1562. 

Au cours de l'etape suivante 1762, il est decide que le paquet ainsi 
desencapsule devient le paquet courant. 

Les etapes 1754 et 1756 sont alors de nouveau effectu^es sur le 
paquet desencapsule afin de lire dans I'en-tete de ce paquet les champs 
"destination_Node_ID" et "source_Node_ID", de lire dans cet en-tete de ce 
paquet les champs "destination_Bus_ID" et "source_Bus_ID" inverse 
represents sur la figure 26 par les champs 1744 et 1746 et d'ecrire dans le 
registre de travail precite les champs 1744 et 1746. 

Dans le cas repr6sente sur la figure 26, le paquet de donn6es 
courant considere ne constitue pas ('encapsulation d'un autre paquet et, par 
consequent, les champs notes 1554c et 1554f sont significatifs, ce qui conduit 
a l'etape suivante 1764 de I'algorithme. 

Au cours de cette etape, il est effectuS un traitement du paquet de 
donnees courant par le pont destination conformement a la description qui en a 
ete faite precedemment et notamment en reference a la figure 6. 

Sur la figure 26, le paquet de donnees 1550 comporte, apres le 
traitement approprie precite, I'ensemble de champs d'information 1734 
comportant des champs notes 1770, 1772, 1774, 1776 et 1554f qui sont 
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identiques aux champs notes 220, 221 , 223, 224 et 204 du paquet de donnees 
226 de la figure 6. 

Toutefois, le champ 1776 correspondant a I'identificateur de routage 
de I'equipement d'interconnexion par lequel le paquet de donnees 1550 quitte 
5 le pont destination n'est pas necessairement identique a I'identificateur contenu 
dans le champ 224 sur la figure 6. 

Le champ denomme "index_D" correspond au champ denommS 
"offset" de la figure 6 et permet de retrouver au niveau du pont destination dans 
la table de routage de celui-ci, I'enregistrement elementaire contenant le 
1 0 descripteur de chemin du paquet de donnees. 

II faut egalement remarquer que cette possibility d'extension de 
I'espace necessaire pour stocker les informations d'identification de chemin 
d'un paquet dans le reseau peut egalement s'appliquer au mecanisme de 
resolution d'adresse, tel que decrit en reference aux figures 12 a 17, ou, par 
15 exemple, une information de descripteur de chemin peut etre de faille 
superieure a vingt bits. 

Le mecanisme de resolution d'adresse doit egalement prendre en 
compte Paspect "inverse" de certains des champs composant ['information de 
descripteur de chemin. 
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REVENPICATIONS 



1 . Procede de traitement d'un paquet de donnees au niveau d'un 
5 pont d'un reseau de communication, ledit paquet de donnees comportant une 

premiere zone reservee au moins en partie a des informations dites 
d'identification d'un chemin pour ledit paquet de donnees dans ledit reseau et 
une deuxieme zone comportant des donnees dites utiles, caracterise en ce que 
ledit procede comporte une etape d'ajout d'au moins une troisieme zone 
10 reservee au moins en partie a d'autres informations d'identification dudit 
chemin dans ledit reseau pour ledit paquet de donnees et qui completent 
lesdites informations d'identification de ladite premiere zone pour constituer 
ledit chemin. 

2. Procede selon la revendication 1, caracterise en ce qu'il 
15 comporte une etape d'ecriture des informations d'identification du chemin dudit 

paquet de donnees dans le reseau dans la premiere zone et ladite au moins 
une troisieme zone de ce paquet. 

3. Procede selon la revendication 1 ou 2, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 

20 une meme structure. 

4. Procede selon la revendication 1 ou 2, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 
chacune une structure differente. 

5. Procede selon I'une des revendications 1 a 4, caracterise en ce 
25 que la premiere zone du paquet de donnees constitue un en-tete. 

6. Procede selon I'une des revendications 1 a 5, caracterise en ce 
que ladite au moins une troisieme zone du paquet de donnees constitue un en- 
tete. 

7. Procede selon I'une des revendications 1 a 6, caracterise en ce 
30 que, le paquet de donnees ayant une longueur donnee avant ajout de la au 

moins une troisieme zone et la premiere zone dudit paquet comportant des 
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informations concernant la longueur de ce paquet " ladite au moins une 
troisieme zone comporte des informations concernant la longueur du nouveau 
paquet de donnees obtenu apres ajout de ladite au moins une troisieme zone 
qui different de celles de ladite premiere zone. 

8. Precede selon I'une des revendications 1 a 7, caracterise en ce 
que, le paquet de donnees ayant un type donne avant ajout de la au moins une 
troisieme zone et la premiere zone dudit paquet comportant des informations 
concernant le type de ce paquet , ladite au moins une troisieme zone comporte 
des informations concernant le type du nouveau paquet de donnees obtenu 
apres ajout de ladite au moins une troisieme zone qui different de celles de 
ladite premiere zone. 

9. Precede selon ia revendication 8, caracteris6 en ce que le type 
d'un paquet definit la fagon dont sont structures les donnees dans le paquet. 

10. Precede de transfert d'un paquet de donnees au niveau d'un 
pont d'un reseau de communication, ledit paquet de donnees comportant une 
premiere zone reservee au moins en partie a des informations dites 
d'identification d'un chemin pour (edit paquet de donnees dans ledit reseau et 
une deuxieme zone comportant des donnees dites utiles, caracterise en ce que 
ledit precede comporte les etapes suivantes : 

- reception (1650) dudit paquet de donnees, 

- detection (1656) d'au moins une troisieme zone ajoutee audit 
paquet, r6servee au moins en partie a d'autres informations 
d'identification dudit chemin dans ledit reseau pour ledit paquet de 
donnees et qui completent lesdites informations d'identification de 
ladite premiere zone pour constituer ledit chemin. 

11. Precede selon le revendication 10, caracterise en ce que 
I'etape de detection consiste a analyser une partie des informations 
d'identification de chemin. 

12. Precede selon la revendication 10 ou 11, caracterise en ce 
qu'il comporte une etape de lecture des informations d'identification du chemin 
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du paquet dans le reseau qui sont reparties dans la premiere et la au moins 
une troisieme zone. 

13. Precede selon I'une des revendications 10 a 12, caracterise 
en ce que la premiere zone et la au moins une troisieme zone du paquet de 

5 donn6es ont une meme structure. 

14. Precede selon I'une des revendications 10 a 12, caracterise" 
en ce que la premiere zone et la au moins une troisieme zone du paquet de 
donnSes ont une structure differente. 

15. Precede selon I'une des revendications 10 a 14, caracterise 
10 en ce que les informations d'identificatiqn du chemin du paquet dans le reseau 

sont respectivement contenues dans deux champs d'informations concernant 
respectivement le chemin a parcourir et le chemin parcouru par (edit paquet de 
donnees et ayant chacun une longueur donnee, ledit precede comportant une 
etape de traitement desdites informations d'identification comportant 

15 notamment les etapes suivantes : 

- suppression d'au moins une premiere information d'un premier 
champ d'informations concernant le chemin a parcourir, reduisant ainsi la 
longueur dudit premier champ d'informations d'une longueur correspondant a 
celle de ladite premiere information, 

20 - ajout d'au moins une deuxieme information dans un deuxieme 

champ d'informations concernant le chemin parcouru, augmentant ainsi la 
longueur dudit deuxieme champ d'informations d'une longueur correspondant a 
celle de ladite deuxieme information. 

16. Precede selon la revendication 15, caracterise en ce qu'un 
25 troisieme champ d'informations appele marqueur delimite les deux premiers 

champs d'informations concernant respectivement le chemin a parcourir et le 
chemin parcouru par le paquet de donnees. 

17. Precede selon la revendication 16, caracterise en ce qu'il 
comporte une etape de decalage des trois champs d'informations. 

30 18. Precede selon I'une des revendications 15 a 17, caracterise 

en ce qu'il comporte, consecutivement a I'etape de traitement des informations 
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^identification du chemin dudit paquet de donnees dans le reseau, une etape 
d'ecriture desdites informations dans la premiere zone et ladite au moins une 
troisieme zone de ce paquet. 

19. Procede de traitement d'un paquet de donnees au niveau 
d'un pont d'un reseau de communication, ledit paquet de donnees comportant 
une premiere zone reservee au moins en partie a des informations dites 
d'identification d'un chemin pour ledit paquet de donnees dans ledit reseau et 
une deuxieme zone comportant des donnees dites utiles, caracterise en ce 
que, ledit paquet de donnees comportant au moins une troisieme zone 
reservee au moins en partie a d'autres informations d'identification dudit 
chemin dans ledit reseau pour ledit paquet de donnees et qui completent 
lesdites informations d'identification de ladite premiere zone pour constituer 
ledit chemin, ledit procede comporte les etapes suivantes : 

-lecture des informations d'identification du chemin du paquet 
dans le reseau qui sont reparties dans la premiere zone et la au moins une 
troisieme zone, 

-suppression de ladite au moins une troisieme zone dudit paquet. 

20. Procede selon la revendication 19, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 
une m£me structure. 

21. Procede selon la revendication 19, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 
chacune une structure differente. 

22. Dispositif de traitement d'un paquet de donnees au niveau d'un 
pont d'un reseau de communication, ledit paquet de donnees comportant une 
premiere zone reservee au moins en partie a des informations dites 
d'identification d'un chemin pour ledit paquet de donnees dans ledit reseau et 
une deuxieme zone comportant des donnees dites utiles, caracterise en ce que 
ledit dispositif comporte des moyens d'ajout d'au moins une troisieme zone 
reservee au moins en partie a d'autres informations d'identification dudit 
chemin dans ledit reseau pour ledit paquet de donnees et qui completent 
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lesdites informations d'identification de ladite premiere zone pour constituer 
ledit chemin. 

23. Dispositif selon la revendication 22, caracterise en ce que la 
premiere zone et la au moins une troisieme zone de paquet de donnees ont 
une meme structure. 

24. Dispositif selon la revendication 22, caracterise en ce que la 
premiere zone et la au moins une troisieme zone de paquet de donnees ont 
chacune une structure differente. 

25. Dispositif selon Tune des revendications 22 a 24, caracteris6 en 
ce qu'il comporte des moyens d'ecriture des informations d'identification du 
chemin du dudit paquet de donnees dans le reseau dans la premiere zone et 
ladite au moins une troisieme zone de ce paquet. 

26. Dispositif de transfert d'un paquet de donnees au niveau d'un 
pont d'un reseau de communication, ledit paquet de donnees comportant une 
premiere zone r6servee au moins en partie a des informations dites 
d'identification d'un chemin pour ledit paquet de donnees dans ledit r6seau et 
une deuxieme zone comportant des donn6es dites utiles, caracteris6 en ce que 
ledit dispositif comporte : 

- des moyens de reception dudit paquet de donnees, 

- des moyens de detection d'au moins une troisieme zone ajoutee 
audit paquet, reservee au moins en partie a d'autres informations 
d'identification dudit chemin dans ledit reseau pour ledit paquet de 
donnees et qui completent lesdites informations d'identification de 
ladite premiere zone pour constituer ledit chemin. 

27. Dispositif selon la revendication 26, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 
une meme structure. 

28. Dispositif selon la revendication 26, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 
chacune une structure differente. 



2794919 

89 

29. Dispositif selon I'une des revendications 26 a 28, caracterise 
en ce qu'il comporte des moyens de lecture des informations d'identification de 
chemin du paquet dans le reseau qui sont reparties dans la premiere et la au 
moins une troisieme zone. 

30. Dispositif selon I'une des revendications 26 a 29, caracterise 
en ce que les informations d'identification du chemin du paquet dans le n§seau 
sont respectivement contenues dans deux champs d'informations concernant 
respectivement le chemin a parcourir et le chemin parcouru par ledit paquet de 
donnees et ayant chacun une longueur donnee, ledit dispositif comportant des 
moyens de traitement desdites informations d'identification comportant 
notamment: 

-des moyens de suppression d'au moins une premiere 
information d'un premier champ d'informations concernant le chemin a 
parcourir, reduisant ainsi la longueur dudit premier champ d'informations d'une 
longueur correspondant a celle de ladite premiere information, 

- des moyens d'ajout d'au moins une deuxieme information dans 
un deuxieme champ d'informations concernant le chemin parcouru, 
augmentant ainsi la longueur dudit deuxieme champ d'informations d'une 
longueur correspondant a celle de ladite deuxieme information. 

31. Dispositif selon la revendication 30, caracterise en ce qu'un 
troisieme champ d'informations appele marqueur delimite les deux premiers 
champs d'informations concernant respectivement le chemin a parcourir et le 
chemin parcouru par le paquet de donnees. 

32. Dispositif selon la revendication 31, caracterise en ce qu'il 
comporte des moyens de decalage des trois champs d'informations. 

33. Dispositif selon I'une des revendications 26 a 32, caracterise 
en ce qu'il comporte des moyens d'ecriture desdites informations dans la 
premiere zone et ladite au moins une troisieme zone de ce paquet. 

34. Dispositif de traitement d'un paquet de donnees au niveau 
d'un pont d'un reseau de communication, ledit paquet de donnees comportant 
une premiere zone reservee au moins en partie a des informations dites 
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^identification d'un chemin pour ledit paquet de donnees dans ledit reseau et 
une deuxieme zone comportant des donnees dites utiles, caracterise en ce 
que, ledit paquet de donnees comportant au moins une troisieme zone 
reservee au moins en partie a d'autres informations d'identification dudit 
chemin dans ledit reseau pour ledit paquet de donnees et qui completent 
lesdites informations d'identification de ladjte premiere zone pour constituer 
ledit chemin, ledit dispositif comporte: 

-des moyens de lecture des informations d'identification du 
chemin du paquet dans le reseau qui sont reparties dans la premiere zone et la 
au moins une troisieme zone, 

- des moyens de suppression de ladite au moins une troisieme zone 
dudit paquet. 

35. Dispositif selon la revendication 34, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 
une meme structure. 

36. Dispositif selon la revendication 34, caracterise en ce que la 
premiere zone et la au moins une troisieme zone du paquet de donnees ont 
chacune une structure differente. 

37. Pont d'un reseau de communication interconnectant au moins 
deux parties dudit reseau de communication, caracterise en ce qu'il comporte 
un dispositif de traitement d'un paquet de donnees selon I'une des 
revendications 22 a 25 ou un dispositif de traitement d'un paquet de donnees 
selon I'une des revendications 34 a 36. 

38. Pont d'un reseau de communication interconnectant au moins 
deux parties dudit reseau de communication, caracterise en ce qu'il comporte 
un dispositif de transfer! d'un paquet de donnees selon I'une des revendications 
26 a 33. 

39. Appareil de traitement de donnees d'un reseau de 
communication, caracterise en ce qu'il comporte un dispositif de traitement d'un 
paquet de donnees selon I'une des revendications 22 a 25 ou un dispositif de 
traitement d'un paquet de donnees selon I'une des revendications 34 a 36. 
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40. Appareil de traitement de donnees d'un reseau de 
communication, caracterise en ce qu'il comporte un dispositif de transfert d'un 
paquet de donnees selon Tune des revendications 26 a 33. 

41. Appareil de traitement de donnees, caracterise en ce qu'il 
5 comporte un pont conforme a Tune des revendications 37 a 38. 

42. Appareil selon la revendication 41, caracterise en ce que ledit 
appareil est une imprimante. 

43. Appareil selon la revendication 41, caracterise en ce que ledit 
appareil est un serveur. 

10 44. Appareil selon la revendication 41, caracterise en ce que ledit 

appareil est un ordinateur. 

45. Appareil selon la revendication 41, caracterise en ce que ledit 
appareil est un telecopieur. 

46. Appareil selon la revendication 41, caracterise en ce que ledit 
15 appareil est un scanner. 

47. Appareil selon la revendication 41 , caracterise en ce que ledit 
appareil est un magnetoscope. 

48. Appareil selon la revendication 41, caracterise en ce que ledit 
appareil est un decodeur. 

20 49. Appareil selon la revendication 41, caracterise en ce que ledit 

appareil est un televiseur. 

50. Appareil selon la revendication 41, caracterise en ce que ledit 
appareil est une camescope. 

51. Appareil selon la revendication 41, caracterise en ce que ledit 
25 appareil est une camera numerique. 

52. Appareil selon la revendication 41, caracterise en ce que ledit 
appareil est un appareil photographique numerique. 

53. Reseau de communication comportant au moins deux parties 
interconnectees par au moins un pont, caracterise en ce que ledit pont est 

30 conforme a I'une des revendications 37 a 38. 
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54. Reseau de communication, caracterise en ce que ledit reseau 
comporte un appareil de traitement de donnees selon I'une des revendications 
39 a 52. 

5 
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